|
|
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Plenty of Web applications rely on JavaScript or some other client-side scripting, yet most developers only measure server-side execution time. Client-side execution time is just as important. In fact, if you're measuring from the end-user perspective, you should also be looking at network time. In this article Srijeeb Roy introduces a lightweight approach to capturing the end user's experience of application response time. He also shows you how to send and log client-side response times on a server for future analysis. Level: Intermediate
Capturing the overall server-side execution time of a Web request is easy to do in a Java EE application. You might write a Filter (implementing javax.servlet.Filter) to capture the request before it hits the actual Web component -- before it reaches a servlet or a JSP, for instance. When the request reaches the Filter, you store the current time; when the Filter handle returns after executing the doFilter() method, you store the current time again. Using these two timestamps, you can calculate the time it takes to process the
request on the server. This gives the overall server-side execution time for each request.
client-response_src.zip is the sample code package that accompanies this article. This sample code package includes two directories -- JavaScripts and JavaSource -- and a text file named web.xml.entry.txt. Inside JavaScripts, you can find two more directories, named OpenSourceXMLHttpRequestJS and timecapturejs. Inside OpenSourceXMLHttpRequestJS you can find the open source Ajax implementation JavaScript file XMLHttpRequest.src.js, which you'll learn about later in this article; inside timecapturejs, you can find a JavaScript file named client_time_capture.js, which contains all the JavaScript that I discuss here.
The JavaSource directory contains all the Java files needed for the sample app discussed in the article, arranged in a proper package structure (inside the com/tcs/tool/filter directory). Last but not least is web.xml.entry.txt, which contains the web.xml entries which you will need to include in your Web application deployment descriptor.
You can also use tools to capture the time of individual method execution. Most of these tools pump additional bytecode inside the classes, with a JAR, WAR, or EAR file; you then deploy the EAR or WAR to instrument your application. (The open source Jensor project provides excellent bytecode instrumentation for server-side code; see Resources.)
These tools are very useful for measuring server-side execution, but it is also important to capture response time from an end-user perspective. Some applications that process server-side requests very quickly still run slowly due to network bottlenecks. Convoluted JavaScript in a page's onload method can also take considerable time to execute, even after the response has traveled back to the browser. Measuring the end-user's perception of response time means accounting for the time required to do the following:
JavaWorld articles by Srijeeb Roy
More from JavaWorld