Performance By Design

This is a continuation of a series of blog entries on this topic. The series starts  here . With the emergence of the Web 2.0 standards that enabled building dynamic HTML pages, web applications grew considerably more complicated, compared to the static view of the page composition process that the YSlow scalability model embodies. Let’s review some of the more important factors that complicate the (deliberately) simple YSlow model of Page Load Time. These complications include the following: YSLow does not attempt to assess JavaScript execution time, something that is becoming more important as more and more complicated JavaScript is developed and deployed. JavaScript execution time, of course, can vary based on which path through the code is actually executed for a given request, so the delay can vary, depending on the scenario requested. The processing capacity of the underlying hardware where the web client that executes the script resides is also a factor. This is especially i

This is a continuation of a series of blog entries on this topic. The series starts  here . The YSlow model of web application performance, depicted back in Equations 3 & 4 in the previous post , leads directly to an optimization strategy to minimize the number of round trips, decrease round trip time, or both. Several of the YSlow performance rules reflect tactics for minimizing the number of round trips to the web server and back that are required to render the page. These include designing the Page so there are fewer objects to Request,  using compression to make objects smaller so they require fewer packets to be transmitted, and  techniques for packing multiple objects into a single request.  For example, the recommendation to make fewer HTTP requests is in the category of minimizing round trips. YSlow rules regarding image compression or the use of “minified” external files containing JavaScript and CSS are designed to reduce the size of Response messages, which, in t

This is a continuation of a series of blog entries on this topic. The series starts  here . In this post, I will begin to  probe a little deeper into the model of web page response time that is implicit in the YSlow approach to web application performance.  The YSlow performance rules, along with Souder’s authoritative book that describes the YSlow corpus of recommendations and remedies in more detail, have proved to be remarkably influential among the current generation of web application developers and performance engineers. The scalability model that is implicit in the YSlow performance rules is essentially a prediction about the time it takes to compose a page, given the underlying mechanics of web page composition that entails gathering and assembling all of the files associated with that page. One benefit of the model is that it yields an optimization strategy for constructing web pages that will load more efficiently. The YSlow performance rules embody the tactics recommend

This is a continuation of a series of blog entries on this topic. The series starts here . In this blog entry, I start to dive a little deeper into the model of web page response time that is implicit in the YSlow approach to web application performance. As depicted in Figure 3, the HTTP protocol defines a simple Request:Response sequence for accessing a document, identified by its Universal Resource Identifier (URI). The web browser issues a GET Request for the resource, receives a Response message in reply, and then composes and renders the document it received inside the web browser. Figure 3. A GET Request issued from the web browser triggers a Response message from the server, which is received by the web client where it is rendered into a web page. This simple picture leaves out many of the important details of the web protocols, including the manner in which the web server that can respond to the GET Request is located using DNS, the Internet Protocol’s (IP) Domain

This series of blog posts picks up on a topic I made mention of earlier, namely scalability models , where I wrote about how implicit models of application scalability often impact the kinds of performance tests that are devised to evaluate the performance of an application. As discussed in that earlier blog post, sometimes the influence of the underlying scalability model is subtle, often because the scalability model itself is implicit. In the context of performance testing, my experience is that it can be very useful to render the application’s performance and scalability model explicitly. At the very least, making your assumptions explicit opens them to scrutiny, allowing questions to be asked about their validity, for example. The example I used in that earlier discussion was the scalability model implicit when employing stress test tools like HP LoadRunner and Soasta CloudTest against a web-based application. Load testing by successively increasing the arrival rate of custo