Overview of JMeter

JMeter 1.9.1, from The Apache Software Foundation, is a 100% pure Java desktop app created to load-test and measure system performance. It originally focused on Web apps but was made extensible and extended. Thus, JMeter can load and performance-test HTTP, FTP, and RDBMS with its support for Java Database Connectivity (JDBC). And, you can write pluggable samplers that perform tests, pluggable timers, and data analysis and visualization plugins. For example, you could write a plugin that allows you test Enterprise JavaBeans (EJBs), Simple Object Access Protocol (SOAP), or Common Object Request Broker Architecture (CORBA) by writing your own custom sampler. Typically, you use JMeter to measure your system performance. At first it may seem that JMeter overlaps with JUnitPerf or HttpUnit. Rather, it complements these tools: You can use JMeter to simulate load while you use JUnitPerf in conjunction with HttpUnit to ensure that your Web app still responds in a timely manner. You can use JMeter to simulate a heavy load on a your system, server, and network. JMeter has a full multithreading framework that allows concurrent sampling by many threads and simultaneous sampling of different functions by separate ThreadGroups. Thus, you can also use JMeter to test system performance under different load types, such as heavy updates, heavy browsing, heavy transactions, or under different combination of load profiles simultaneously. An advantage of using JMeter is that you get instant visual feedback of system performance with its graphs and splines. Because JMeter can load test a site using HTTP, it can be used to test performance of both static and dynamic resources: files, Java servlets, Perl CGI, Python CGI, PHP, JavaServer Pages (JSP), Cold Fusion, Active Server Pages, and more.

One company hired me three days before launch. I spent the first three days untangling a connection-pooling problem. The product (an e-commerce Web site) launched the same day the customer company was showing the Web site at a convention. You could say the Web site was the star of the show. Expectations grew. Unfortunately, the Web site did not scale. I spent the month working 100-hour weeks in an effort to re-architect a site that was in production, making many patch releases. We made steady improvements, and before the end of the month the site was performing very well. Then, without warning, the customer company did a major marketing blitz and the site got twice as many hits as before in a matter of days. At this point, I began sleeping at work because I was there so much.

It took another month of 100-hour+ work-weeks to get the site up to speed again. The moral of the story is that a little planning and performance monitoring up front can save you a lot of heartache and late nights, and you may avoid angering your customer and burning out your employees.

Previous Next