Performance Load Testing – 0

Some projects we work on, gives us a deja vu feeling. One feels like “I have been thru this already” … “Oh … the same old thing again”. But some projects take us into an unchartered territory. There is a sense of fear (of failure) and a sense of challenge. Intense learning comes from sincerely working on such projects. Such opportunities don’t come by very often. Recently, I had one such experience with Performance Load Testing of a web application.

This wont be a how-to-do a performance testing kind of a thing. There are already many, written by experts. Instead, I would focus on 4 key learnings that I derived out of this experience. I feel, this is unique in its own way, and hence worthy of being shared.

This will be the first part of the 5 part post that I intend to blog. In this introductory post, I shall set the context and name the four key learnings. I do this, partly, to commit myself to write about the four learnings in detail in the coming days.

The Context
For an online competition product, I had to estimate the safe concurrent load that it can take on a server of a given configuration. The web application is built on J2EE (using Servlets & PoJos).

We used a completely Open Source stack

Server – Dell 6950, 12 GB RAM, 4 Dual Core AMD 8214, 64 bit
OS – CentOS 5
Load Balancer – HAProxy
Web Server – Tomcat 5.5
Database – MySQL 5
Development – Java Servlets, Java POJOs, FreeMarker, JavaScript

The Java Runtime Environment used was a 32bit environment (which means only 2 GB max memory per VM, btw we use Sun jdk 1.5.x ).

The key learnings were
1. Know your load
2. Know your tool
3. Know what to expect
4. Use your brains

More on these learnings soon.

A ‘relay’ blog post

When I come across blog posts that merely link to something else and not much meat from the author, I used to feel that it is a blog post for the sake of it. Such blog posts serve as a ‘relay’ or ‘repeater’ for the original post.

However, relaying-blogposts do have some advantages like for example
1) If the original post is a very helpful one ( for eg., a technical tip) and not very popular, ‘relay’ing increases the reach.
2) search engines rate these original posts higher and so better chances of a good post reaching the needy through a search.

Now, why am I saying all this ? Only because I too want to relay a particular piece of information. In this case, It is not a blog post but a mailing list posting.

We use tomcat clustering (behind Apache) with MS SQL. There occurs strange problems at the strangest of times. No connections to the database becomes available thereby raising availability concerns. Search Engines did not prove to be very efficient. Searching for “tomcat MS SQL” does indeed give (too many) results, but it is the case of finding the needle in a haystack. Most of the results are the case where they are not able to connect to MS SQL even for the first time. But, my problem is that everything works fine for sometime and THEN one fine day it conks. And this “sometime” varies. The time between failure varies as much as 1 day to 3 months.

Finally, I could nail down a post that *exactly* described my problem and some good Samaritan has provided some suggestions too. Here it is !