The first XKE in our new places gave rise to very curious stages: bisounours booed garbage cans under the scoffing look of pokemons! And, no, the cardboards of move did not fall to us on the head. It was only some some of the names chosen by teams there 3 - 4 consultants, that measured in a competition of tuning of performance, on an application standard Popular dance EE, bugg e (voluntarily, for time) by the masters of ceremony, Guillaume Bodet and . All participants saw each other delaying VM, containing Tomcat, an application (PetClinic of Spring, seen again and "corrected ") and scripts of performance JMETER. The source code had not given, at first.

For all, the only purpose: make diminish the time of answers of application.

Rules were the following:

• A bug is considered as found only when he was identified, that a corrective was offered and that proof is made that this corrective allows to improve response time significantly.
• There are three levels of difficulty, going from the obvious bug to the craftiest anomaly.
• The choice of tools is free.

In your marks... Loans? D buggez!

Preamble

One of the purposes of this XKE was to be very didactic, in research methods and in use of tools. Bombs put in code allowed to accomplish a linear progress (in difficulty as in waited earnings). This progress is retranscribed in this article and those who are going to follow.

However, for different reasons which we will have opportunity to explain, the order of analyses, and therefore of discoveries of bugs, is not the one that would have chosen a champion of performance, I named Kirk Pepperdine. We subjected him our application, and we will display you its method of analysis and the reasons which motivate it in the last article of series.

First contact with application...

Opening of the navigator, entered of url, and, no surprise, PetClinic application opens.

First launching of JMETER, and first observation: with the single user, application puts on average more than 2 seconds to be answered. Unacceptable for most sites web (especially with the single active user).

... and first regulatings

At first glance, the machine does not seem to knees, it is therefore possible to accuse application directly.
We are therefore going to try to know what she makes. A classical reflex, which had to some us, is to go to open logs. Catalina is empty, there is not directory of logs applicatives hollow out, in priori guilty classic, shape log4j, is to move aside. And however... To know what indeed makes our application, it is possible to accomplish a series of thread dumps. For it, two possibilities:

• the old school, which goes to dumper the contents of threads with the aid of a kill-3 on the jvm.
• the modern school, which is going to use (and its plugins) to accomplish the same operation with the aid of nice interface.

And there, half surprise, our active thread is often surprised in method org.apache.log4j.spi.LoggingEvent.getLocationInformation. We would have therefore an active logger. Our initial suspicion is confirmed, do not stay more than to bring the culprit to light.
We have no source code. And yet this bomb fills application so much that it is not possible that we could not solve it in succession. It is therefore necessary to have a file of definition of parametres of the log externalis . There still, VisualVm is going to help us. In the overview window, the parametres of starting of VM are shown. And they see apparaitre a directive of shape log4j, -Dlog4j.configuration.

A grep baby in the directory of launching of Tomcat ($TOMCAT_HOME/bin), and we see appearing in the setEnv the line -Dlog4j.configuration=file:$CATALINA_HOME/conf/log.xml. And if we open this file, the root logger is well in DEBUG. But no specific directive to logger elsewhere that in the console. Everything should therefore go to catalina.out. This smells the 'wild ' redirection. Let us continue going through the files of launching. A small turn in catalina.sh, and surprised, a nice redirection Unix "$CATALINA_BASE"/logs/catalina.out 1> /var/log/catalina/tomcat.log &
And by opening this file, the lost time is better understood: thousands of lines of DEBUG!

Those ci have besides a nice feature: in every line of DEBUG, the numero of line of classified it Popular dance is pointed out.
It is practical! Why do not put they systematically puts this shape on our plans?
A small turn in material Log4J learns us:

Log4J tells us, these methods are under competitive. If they dig little in source, they find the class showing pattern %M and %L, org.apache.log4j.spi.LocationInfo, which contains the following constructor:

In other words, for every line of log, Log4J generates a stackTrace to be able to recover the number of the line and the name of method. Not really competitive.
Let us change the pattern therefore and let us notice result.

• Abolition of %M: % L in the pattern of logger
• Medium time of 2,3 s in 2,0 s for 1 user
• 2 points for the team which found

Always concerning this file of log, we see appearing a line not respecting PatternLayout of Log4J, pr fix e by Hibernate, who draws a request SQL. Let us remember this line, we will rethink there when we will have the source code.

Second possible immediate improvement, an application, what's more in production, should not need a level of log so fine. Let us cross therefore in ERROR.

• logger from DEBUG to ERROR
• Medium time of 2,0 s in 1,75 s for 1 user
• 1 point for the team which found

We made a fate to the logger. But we have not finished it with the out-of-the-box shape of this application yet.

Source