How to Test a Server

response time versus the number of users e.g., When there are 30 users, the average response time is 134 milliseconds for a withdrawal. What wed love is a flat relationship: constant response time as the number of users increase. But since each additional user will consume extra resources and computing time, thats impossible once a server starts to get busy. The best we can hope for is a linear relationship between the number of users and the the response time. This is hard to achieve. How does the application behave over long-term usage? The issues here revolve around the performance of the server when you leave it running for an extended period of time. Does it leak memory? Does it gradually lose the ability to respond? The memory and resource footprint of the server when it has no clients should be the same, no matter how long the servers been running. And the server should have the same performance characteristics after five weeks in operation as when it was first started. If this isnt the case, and there is no explanation for why the servers profile has changed, then the server is not ready to be deployed.

13.1.2 How to Test a Server

Testing all of this stuff might seem like a tall order, requiring lots of code and an advanced degree in mathematical statistics. And the truth is that it does involve a fair amount of code. However, its also the case that a little bit of work can go a long way. Coding up some simple tests, and checking them repeatedly during the development cycle, can save a great deal of time and effort later on. The basic testing strategy involves the following seven steps: 1. Build simple test objects. These are objects that test if a single server object works correctly and measure the time a given operation takes. An important, and often overlooked, point is that its not enough to test that the server functions correctly when good arguments are passed in. The server must be able to detect incorrect method calls and respond appropriately. In this section, Im coming awfully close to advocating what the proponents of Extreme Programming XP refer to as unit testing. If this was a general methodology book, I would strongly advocate unit testing. But, since this book is about RMI, Ill simply refer you to the definitive XP web site for more information. It can be found at ht t p: w w w .xpr ogr am m ing.com . 2. Build aggregate tests that test entire use cases. For complex applications, it is often useful to build aggregate tests that correspond to the use cases. Just as a use case is a sequence of user actions, an aggregate test is a sequence of simple tests. 3. Build a threaded tester that repeatedly performs these tests. This is usually just a subclass of Thread that knows how to repeatedly perform tests. Its not very complex, but it does need to be in a separate thread because the tester is, more or less, analogous to a sequence of users. 4. Build a container that launches many testers and stores the results of the test in an indexed structure. The next step, now that youve built a threaded tester that can perform lots of tests, one after the other, is to add a piece of code that launches many testers. Once this is done, you have the ability to perform many concurrent operations over a long period of time. That is, you can perform a crude simulation of a large client load. 5. Build a reporting mechanism. Testing is useless unless you can access the results. This can be a simple GUI that says tests succeeded, or it can be a complex database containing all sorts of information about each test performed. The complex database can be a great idea if youre interested in finding out how performance and scalability change over time. If youre just interested in making sure the application works, its usually not necessary. 6. Run the tests repeatedly. You should run simple, low-load tests very often to test whether the server objects are still correct, preferably as part of a daily build process. Scalability tests, in which you simulate hundreds of clients and watch the system try to cope, should also be run often. However, since theyre not quite as important for day-to-day development and consume more resources, they dont need to be run as frequently. 7. Profile using your scale tester. If you run the servers inside a profiler, and then launch a large-scale test, you will find where your application bottlenecks are located. Profilers are really the only way to learn about application performance, and the beauty of a testing framework is that it lets you do intensive profiling of your application under load without deploying it.

13.1.3 Testing the Bank Application