Databases Reference
In-Depth Information
Performance Testing
In performance testing, your objective is to measure how fast you can get something done, and not how
many of something you can do, which is subtly different. What does this mean? In a performance test
you need to give the test subject (your disks) one thing to do (one I/O request), and then see how quickly
it gets done. Then you give it another thing to do and see how quickly it does that. Basically you throw
sequential requests at the test subject, and observe how long each one takes.
You have to be a little careful that your performance test doesn't turn into a stress test, and in some
cases your performance test might start to look a bit like a stress test, but your focus is always on how
quickly you got the job done, and not in how many you could get done.
Stress Testing
In stress testing the objective is to apply stress to the system and see how it holds up. In a stress test
you throw many concurrent requests at the test subject and see how it responds. In comparison with the
performance test, which was a sequential test, the stress test is a parallel test. And your focus here is on
howmany requests you manage to process in the allotted period. Another part of the stress test is usually
concerned with correctness. It's no good getting a great number if half the results are wrong.
Real-LifePerformance
In attempting to assess real-life performance, the objective is to assess both how quickly a single response
may be served (a performance test) and also how many you can do at the same time (a stress test).
Real-life performance is also concerned with more complex operations than you would have looked
at in either the performance or stress tests. In the performance and stress tests, you were interested in
much smaller units of work, such as a single disk's I/O or a few disks' I/O together. In a real-life test you
are interested in the actual units of work a user might do. In this case you must then have some concept
of the way that a real user interacts with the system and exactly what database and I/O operations each
user might cause.
A common way of looking at this is to use the use-case methodology to model the system's users and the
interactions those users have with the system (the cases).
A simple example of this comes from a system I worked on long ago. It was a telecom company's
billing system. In this instance, a user would be the telephone company's users, the billing system,
oracustomerservicerep.Takeforexamplethecustomer service rep (CSR). One task the CSR has to
perform is to answer billing queries from the customer. To do this he or she has to perform many queries
to get the data they want. A typical case might be for the CSR to start by issuing a search query to find
the customer's account based upon any one of the acceptable account identifiers: the customer's address,
phone number, account number, address, and so on. From there the CSR can query for all the call records
for a given time period, and from there pull up the details of a specific call record. This may then result
in an update, or a write of a new record to indicate a customer query on the bill that needs further
investigation by some other part of the company.
So in this use case, you have the following DB operations:
❑
Customer search query
❑
Customer account details query
Search WWH ::
Custom Search