Here is a simple test you can do to help isolate performance problems in complex n-tier environments – it’s called the static HTML page test. I’ve used it many times over the years, and I just busted this one out last night in a customer test. It’s invaluable. Here is the scenario:
You’re performance testing an application and there’s a bottleneck somewhere. But where? In an n-tier environment the requests usually follow a trail that looks something like this:
Load Balancer -> Web Server -> App Server -> Database
By creating a simple static page with an .html extension on it (very important), you take the last two tiers of the request chain out of the equation. The .html extension is important because web servers know where to route the requests for content based on their extension. When something comes through with .jsp, .aspx, or .php on it, the web server knows to send that request to a Java app server or through the PHP/ASP page processor. If the extension is .html, the web server will serve it up itself. Note that this is true in most cases. While rare, it may be the case that web server settings or web application settings in your environment are having your .html pages served out of the app server. This is really really bad. In general, HTML should be served by the web tier (Apache, IIS, etc).
So why is this test valuable? Let’s say you’ve been running a performance test that has a user hitting the homepage, browsing a product catalog, and adding an item to the shopping cart. Over multiple tests you haven’t been able to push more than 200 hits per second and 7MBit per second of throughput. You throw a static page on the web tier and it just so happens that you can drive 1000 hits per second and 35MBit per second of bandwidth. In this simple test you just ruled out bandwidth problems, thread count settings in your web servers, and connection limitations on switches, load balancers and firewalls… to name a few of the bigger ones.
Simple test, huge results. Happy testing!
About the Author