Record performance data for Java WEB applications with AOP

As a developer, application performance has always been one of our most interesting topics. However, not all developers are aware of the performance of their own applications, let alone quickly locate performance bottlenecks and implement solutions.

This year, Beijing Velocity's sponsors are mostly in the APM field, providing performance profiling, visualization, and even optimization solutions. These vendors ' products seem to be good at helping small and medium-sized developers solve their application performance flaws, but these products almost have a fatal flaw: extremely intrusive.

Developers need to embed the embedded code provided by APM vendors in their business production code to be able to use the Saas services provided by APM vendors. In a rapidly changing technology landscape, this code-level intrusion and binding always makes developers worry. If I were an architect, I would also consider it carefully on my own APM or Saas APM.

However, whether you build APM or use Saas services, the underlying model is just the real-time processing of massive logs, and the data source is the performance log generated by the application.

If we have the data, let's look at data. If all we have is opinions, let's go with mine.

Jim Barksdale

This is a data for the king of the era, exaggerated a little, the data can guide everything!

If we do not want to use the aggressive services that APM is trying to provide, we can only build our own services, such as AOP to collect thread-in-call trees and call overhead and output logs, then use ELK (Elasticsearch, Logstash, and Kibana) To collect logs and provide search, visualization and other functions. If the collected log is used only as an offline calculation, you can write the log directly to HDFS using Flume.

As the system flows more and more, the above scheme will not be able to carry, and then need to achieve high-performance log collection Agent, the collected logs a brain write Kafuka such as can carry a large number of messages in the MQ, and then use Storm/jstorm to do real-time streaming calculation.

Some days ago, I made a simple attempt to crawl the call tree and overhead based on AOP, feeling a bit interesting and sharing.

Fetch Call tree and time overhead

The most common way to get the time overhead for code blocks in Java is System.currentTimeMillis() . Popular class libraries such as Apache and guava have encapsulation class StopWatch for the ability to acquire time overhead.

There is no common encapsulation of the capture call tree. A recommended practice is to give each block of code a unique tag in a single call, which can reflect the nesting, ordering, and so on between blocks of code.

To raise a chestnut, we have the following call relationship.

func1+- func2|  +- func3|  /- Func4/-Func5

In order to reflect the nesting and order between calls, we give func1 tag 0, give Func2 tag 0.1, give func3 tag 0.1.1, Func4 Mark 0.1.2, give Func5 mark 0.2. In this way, we can easily reconstruct the call tree based on the tag.

We can wrap the call tree's fetch and record the time overhead of each block in a thread-safe manner, giving the package a name similar to that of the Profiler. The Profiler provides 2 static methods, and enter is called before the code block is entered, and exit is called after the code block ends.

When implementing the Profiler, you need to maintain a call stack for each thread, as well as a list of profiling results. Basically can be implemented as enter the stack, exit stack and put the results into the results list, when the call stack back empty, output a complete analysis results.

AOP and Method interceptors

Profiler has a strict implementation of the Convention, that is, enter and exit must be called in pairs, just like C + + inside the new and delete must be the same, otherwise the memory will be directly exploded, far from memory leaks so simple.

This kind of convention if writes to the business code, the death is very difficult to see, the various try finally abruptly the business logic to break, originally the business code is already very disgusting, such a thing is impossible to maintain.

So we need a more scientific way to implement the correct invocation of the Profiler in a non-intrusive way. AOP is a suitable tool.

Take Spring AOP as an example to implement a simple example.

First introduce the dependency of Spring AOP, or the package containing org.aopalliance.intercept.MethodInterceptor.

<dependency>    <groupId>org.springframework</groupId>    <artifactId>spring-aop< /artifactid>    <version>2.5.6</version></dependency>

If you need code to work, you also need to introduce cglib dependencies.

<dependency>    <groupId>cglib</groupId>    <artifactid>cglib-nodep</artifactid >    <version>2.2</version></dependency>

The reference implementation of the method interceptor is as follows, using code pattern like try finally to ensure that the Profiler is used correctly.

 Public classInterceptorImplementsMethodinterceptor {@Override PublicObject invoke (Methodinvocation invocation)throwsthrowable {Class clazz=Invocation.getmethod (). Getdeclaringclass (); String Method=Invocation.getmethod (). GetName (); String Mark= Clazz.getcanonicalname () + "#" +method;        Profiler.enter (Mark); Try {            returninvocation.proceed (); } finally{String log=Profiler.exit (); if(Log! =NULL) {System.out.println (log); }        }    }}

Logging performance data for Java WEB applications with AOP