Mohsen Vakilian's Blog

June 15, 2007

Performance Test Scripts

Filed under: performance — mohsenvakilian @ 3:09 pm

Performance Analysis for Java Web Sites

Have you ever had to write test scripts for performance testing your web application?
If so, I recommend you to read the seventh chapter of the book entitled “Performance Analysis for Java Web Sites“.

What do we mean by a good test script?
A test script results in a valuable performance test when it models the real users’ behavior correctly.

In the chapter entitled “Test Scripts”, the authors explain how to develop flexible and dynamic test scripts. Then, they talk about building test scenarios out of test scripts using weights to better model the usage pattern. At the end, they list some of the common pitfalls many test scripts suffer from.

In my opinion, the most challenging part of developing a performance test script is adding the dynamicty of real users to our virtual users. This dynamicity requires an intelligent performance tool which can dynamically decide what to do in each state. Several performance tools such as LoadRunner and SilkPerformer have tried to provide this dynamicity and parameterization by modifying the generated test scripts. But, it seems that they are far from a mature, easy to use, and intelligent performance test tool.


June 7, 2007


Filed under: performance — mohsenvakilian @ 4:50 pm

As my BS project is about performance analysis of Web based applications, I have become too curious about performance stuff these days.

Recently, I watched a video interviewing Jim Kelly about “performance monitoring”. Here, I have brought the points interesting to me in his talk.

Glassbox is an Open Source project for diagnosis of performance problems built on aspect-oriented programming that interfaces with your JVM and looks for commonly occurring problems. The tool instruments the Java Code to look for precisely top ten things that break most applications. The main advantage of Glassbox is eliminating the burden of examining horrible log files generated by most performance diagnosis tools.

“There is a rule that the person who wrote the code should not be the one to test the code because you tend not to see it very objectively, and I think the same thing is true of cracking down performance problems that even if you are aware of problems at some level, you may not be able to call those out.”, said Jim Kelly.

I quite agree with Jim on the psychological block he points out. I have felt the same in several of my debugging experiences.

At last, Jim gives some advice to those facing performance problems at the time. It’s interesting that his advice is somehow psychological, too. The following is the advice:

“Don’t panic because I think all the problems get harder as soon as you get a lot of people involved and as soon as you lose your ability to think very carefully about the data you are seeing.”

Create a free website or blog at