What is Response Time?
One of the primary goals of Software Performance Engineering is to satisfy the response time as defined by Service Level Agreements (SLAs). Response time is one of the simplest concept yet it is not fully understood by many.
Let us take a real world example. You go to a restaurant and place an order for lunch. What is the total time to execute this order? Let’s look at the sequence of events. The waiter spends some time taking your order and then places it as the last item in a queue of orders. When this order reaches the top of the queue one of the cooks takes this order and cooks the dish and when it is ready the waiter brings it to your table. So the total time for your order is the sum of processing time ( time to take order + cooking time) and the wait time ( time the order was in the queue).
Response time can be defined as the total time taken to perform an action. This total time could include time processing the action ( in the app server, database, client etc.) and the time spent waiting ( network, IO, memory..). In Software Performance Engineering, Response Time can be surmised as sum of processing time and wait time.
Lets take an example from software engineering. In unix there is a utility “time” or “timex” for measuring the elapsed time for a particular process. We will be looking at a granular level, analyzing a particular process within a system and not the response time for a particular action through the whole solution. Let’s say your application process is “myapp”, you can run the time command on that application as below.
4.6 real 0.5 user 0.8 sys
The output shows that the elapsed time ( real time or the response time perceived by the user) for running the “myapp” process is 4.6 seconds. The total CPU time for running this process is 1.3 CPU seconds, out of which 0.5 cpu seconds is spent in user mode and 0.8 cpu second in system mode (kernel). Where is the rest of the time? How do you account for 3.3 seconds.
Time could have been spent performnig I/O operation some of which is attributed to system time, but time spent by disk drives, network interfaces, terminal controller, or other hardware is not accounted for by the “time” command. Time could have been also spent running jobs on behalf of other users ( context switching) or waiting for memory. Many different components contribute to a program’s elapsed time.
Some of the notable elements for the breakup of elapsed time is as follows
- User CPU Time : The amount of time the CPU spends running user’s program in user state ( executing library function but excluding time spent in kernel).
- System CPU Time: The amount of time the CPU spends in the system state ( amount of time executing kernel code ).
- I/O time: The amount of time the I/O Subsystem spends servicing I/O requests by the process.
- Network time: The amount of time the I/O Subsystem spends servicing the netwrok requests that the job issues.
- Time spent running other programs: As the load increases, the CPU will spent less time on a particular program and will be switching between programs to give them some slice of time.
- Virtual Memory: Ideally all the programs remain in the system’s memory, but when the memory is overloaded and not all program’s can exist in the memory, the system starts paging memory to and from the disk therby increasing the time spent servicing memory request.
The bottom line is Response time = Processing Time + Wait Time.
Oracle has also changed the way they collect and report performance. The impetus is on wait time. Oracle introduced Oracle Wait Interface ( OWI) in 7.0.12 but it has really matured 10g onwards. This interface provides wait time metrics for numerous events. Mostly the response time degrades significantly due to high wait time and if you can reduce the wait time you can really improve the response times. I will cover OWI in a different post. Also there are system tools ( sar, iostat etc.) which give good indication of the wait time at the system level, those will also be covered in a different post.
Refernces: System Performance Tuniong (Mike Loukides, O’Reilly)