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.
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 Naming Service. But it will suffice to frame a definition of web application response time, which is measured from (1) the time the GET Request was issued by the browser, includes the time it takes to locate the web server, (2) the time it takes the web server to create the Response message in reply, the network transmission time to send these messages back and forth, and, finally,Ž (3) for the web browser to render the Response message appropriately on the display. The response time for this Request is measured from the time of the initial GET Request to the time the browser’s display of the Response is complete such that the customer can then interact with any of the controls (buttons, menus, hyperlinks, etc.) that are rendered on the page. This response time measurement is also known as Page Load Time. The YSlow tool incorporates a set of rule-based calculations that are intended to assist the web developer in reducing page load time.
Elsewhere on this blog, I have expounded at some length on the limitations of the ask-the-expert, rule-based approach, but there is no doubting its appeal. It makes perfect sense that someone who encounters a performance problem and is a relative newcomer to web application development would seek advice from someone with much more experience. However, when this expertise is encapsulated in static rules, and these rules are applied mechanically, there is often too much opportunity for nuance in the expert’s application of the rule to be missed. The point I labored to make in that earlier series of blog posts was that, too often, the mechanical application of an expert-based rule does not capture some aspect of its context that is crucial to its application. This is why in the field of Artificial Intelligence the mechanical application of rules in so-called expert systems gave way to the current machine learning approach that trains the decision-making apparatus based on actual examples[1]. On the other hand, understanding how and why an expert formulated a particularly handy performance rule is often quite helpful. That is how human experts train other humans to become expert practitioners themselves.
In essence, as Figure 3 illustrates, HTTP is a means to locate and send files around the Internet. These files contain static content, structured using the HTML markup language so that they contain the instructions the web client needs to compose and render them. However, many web applications generate Response messages dynamically, which is the case with the specific charting application we are discussing here in the case study. In that example, the Response messages are generated dynamically by an ASP.NET server-side application based on the machine, date, and chart template selected, which are all passed as parameters appended to the original GET Request message sent to the web server to request a specific database query to be executed.
As depicted in Figure 4, the HTTP protocol is layered on top of TCP, which requires a session-oriented connection, but HTTP itself is a sessionless protocol. Being sessionless means that web servers process each GET Request independently, without regard to history. In practice, however, more complex web applications, especially ones given to generating dynamic HTML, are very often session-oriented, utilizing parameters appended to the GET Request message, cookies, hidden fields, and other techniques to encapsulate the session state, reflecting past interactions with a customers and to link current Requests with that customer’s history. A canonical example is session-oriented data to associate a current GET Request from a customer with that customer’s shopping cart filled with items to purchase from the current session or retained from a previous session.
Working our way down the networking stack, the TCP protocol sits atop IP and then (usually) Ethernet at the hardware-oriented, Media Access level. These lower level networking protocols transform network requests into datagrams and from there into packets to build the streams of bits that are actually transmitted using the networking hardware. For mainly historical reasons, the Ethernet protocol supports a maximum transmission unit (MTU) of approximately 1500 bytes. Note that each protocol layer in the networking stack inserts its addressing and control metadata into a succession of headers that are appended to the front of the data packet. After accounting for the protocol headers, the maximum capacity of the data payload is closer to about 1460 bytes. The Ethernet MTU requires that HTTP Request or Response messages that are larger than 1460 bytes be broken into multiple packets by the IP layer at the Sender. IP is also responsible for reassembling the packets at the Receiver. These details of the networking protocol stack are the basis in YSlow for the performance rules that analyze the size of the Request and Response messages that are used at the level of the HTTP protocol to compose the page.
Figure 4. The networking protocol stack.
A further complication is that many web pages are composed from multiple Response messages, as depicted in Figure 5. Typically, the HTML that is returned in the original Response message contains references to additional files. These can and often do include image files that the browser must display, style sheets for formatting, video and audio files that the browser may play, etc. In the web charting application I am using as an example here, the charts themselves are rendered on the server as .jpg image files. The HTML in the original Response message references these image files, which causes the browser to issue additional HTTP GET Requests to retrieve them during the process page composition. Of course, the server-side application builds a .jpg file for each of the two charts that are to be rendered when it builds the original Response message. In order to display presentation-quality charts, the jpg files that are built are rather hefty, given that they must be transferred over the network to the web client. The GET Requests to retrieve these charts fully rendered on the web server in jpg form generate a very large Response message that then requires multiple data packets to be built and transmitted.
So, composing web pages may not only require multiple GET Requests to be issued as a result of <link> tags, Response messages that are larger than the Ethernet MTU require transmission of multiple packets. The number of networking data transmission round trips, then, is a function of both the number of GET Requests and the size of the Response messages. For the sake of completeness, note that whenever the size of a GET Request exceeds the MTU, the GET Request must be broken into multiple packets, too. The most common reason that GET Requests exceed the Ethernet MTU is when large amounts of cookie data need to appended to the Request.
Both the number of files that are requested to render the page and the file size are factors in the YSlow performance rules. For example, the HTML returned in the original Response message generated by the ASP.NET application may reference external style sheets, which are files that contain layout and formatting instructions for the browser to use. Formatting instructions in style sheets can include what borders and margins to wrap around display elements, the size and shape of what fonts to use, what colors to display, etc. The example app does rely on several style sheets, but none of them are very extensive or very large. Still, each separate style sheet file requires a separate GET Request and Response message, and some of the style sheets embedded in the document are large enough to require multiple packets to be transmitted.
Finally, the HTML can reference scripts that need to be loaded and executed when the document is being initially displayed. Scripts that modify the DOM by adding new elements to the page or changing the format of existing elements dynamically are quite common in web applications. Usually written using JavaScript, script code can be embedded within the original HTML, bracketed by <script></script> tags. However, to facilitate sharing common scripts across multiple pages of a web application, JavaScript code to manipulate the DOM can reside in external files, too, that then must be requested and loaded separately.
That is enough about JavaScript for now, but we will soon see that dynamic manipulation of the DOM via the execution of script code running inside the web client, usually in response to user interaction, has the potential to complicate the performance analysis of a web application considerably. It is worth noting, however, that YSlow does not attempt to execute any of the scripts that make up the page. Like the other HTTP objects that are requested, YSlow only catalogs the number of JavaScript files that are requested and their size. It does not even begin to attempt to understand how long any of these scripts might take to execute.
The central point is that page composition and rendering inside the browser frequently requires a series of GET Request and Response messages. The original Response message to a GET Request contains links to additional data files – static images, style sheets, JavaScript files, etc. – that are embedded in the HTML document that was requested. Each additional resource file that is needed to compose the page requires an additional GET Request and a Response Message from the web server. Consequently, the simple depiction of Page Load Time shown in Figure 3 gives way to the more complicated process depicted in Figure 5. When all the resources identified by the web client to compose the page are finally available and processed, the document composition process is complete. At that point, the page load state of the page is finalized, which means it is available to the end user to interact with.
Take a minute to consider all those times that you encounter a web page where the page is partially rendered, but is incomplete and the UI is blocked. The web browser has its instructions to gather all the HTTP objects that the web page references, and you are not able to interact with the page until all the objects referenced in the DOM are resolved. But if the Response message for any one of those objects is delayed, the page is not ready for interaction. That is what Page Load time measures.
Figure 5. Composing web pages usually requires multiple GET Request:Response message sequences due to links to external files embedded in either the original Response message or in subsequent Response messages. It is not until all external references are resolved that the Page can reach its “loaded” state where all the controls available on the page are available to use.
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 Naming Service. But it will suffice to frame a definition of web application response time, which is measured from (1) the time the GET Request was issued by the browser, includes the time it takes to locate the web server, (2) the time it takes the web server to create the Response message in reply, the network transmission time to send these messages back and forth, and, finally,Ž (3) for the web browser to render the Response message appropriately on the display. The response time for this Request is measured from the time of the initial GET Request to the time the browser’s display of the Response is complete such that the customer can then interact with any of the controls (buttons, menus, hyperlinks, etc.) that are rendered on the page. This response time measurement is also known as Page Load Time. The YSlow tool incorporates a set of rule-based calculations that are intended to assist the web developer in reducing page load time.
Elsewhere on this blog, I have expounded at some length on the limitations of the ask-the-expert, rule-based approach, but there is no doubting its appeal. It makes perfect sense that someone who encounters a performance problem and is a relative newcomer to web application development would seek advice from someone with much more experience. However, when this expertise is encapsulated in static rules, and these rules are applied mechanically, there is often too much opportunity for nuance in the expert’s application of the rule to be missed. The point I labored to make in that earlier series of blog posts was that, too often, the mechanical application of an expert-based rule does not capture some aspect of its context that is crucial to its application. This is why in the field of Artificial Intelligence the mechanical application of rules in so-called expert systems gave way to the current machine learning approach that trains the decision-making apparatus based on actual examples[1]. On the other hand, understanding how and why an expert formulated a particularly handy performance rule is often quite helpful. That is how human experts train other humans to become expert practitioners themselves.
In essence, as Figure 3 illustrates, HTTP is a means to locate and send files around the Internet. These files contain static content, structured using the HTML markup language so that they contain the instructions the web client needs to compose and render them. However, many web applications generate Response messages dynamically, which is the case with the specific charting application we are discussing here in the case study. In that example, the Response messages are generated dynamically by an ASP.NET server-side application based on the machine, date, and chart template selected, which are all passed as parameters appended to the original GET Request message sent to the web server to request a specific database query to be executed.
As depicted in Figure 4, the HTTP protocol is layered on top of TCP, which requires a session-oriented connection, but HTTP itself is a sessionless protocol. Being sessionless means that web servers process each GET Request independently, without regard to history. In practice, however, more complex web applications, especially ones given to generating dynamic HTML, are very often session-oriented, utilizing parameters appended to the GET Request message, cookies, hidden fields, and other techniques to encapsulate the session state, reflecting past interactions with a customers and to link current Requests with that customer’s history. A canonical example is session-oriented data to associate a current GET Request from a customer with that customer’s shopping cart filled with items to purchase from the current session or retained from a previous session.
Working our way down the networking stack, the TCP protocol sits atop IP and then (usually) Ethernet at the hardware-oriented, Media Access level. These lower level networking protocols transform network requests into datagrams and from there into packets to build the streams of bits that are actually transmitted using the networking hardware. For mainly historical reasons, the Ethernet protocol supports a maximum transmission unit (MTU) of approximately 1500 bytes. Note that each protocol layer in the networking stack inserts its addressing and control metadata into a succession of headers that are appended to the front of the data packet. After accounting for the protocol headers, the maximum capacity of the data payload is closer to about 1460 bytes. The Ethernet MTU requires that HTTP Request or Response messages that are larger than 1460 bytes be broken into multiple packets by the IP layer at the Sender. IP is also responsible for reassembling the packets at the Receiver. These details of the networking protocol stack are the basis in YSlow for the performance rules that analyze the size of the Request and Response messages that are used at the level of the HTTP protocol to compose the page.
A further complication is that many web pages are composed from multiple Response messages, as depicted in Figure 5. Typically, the HTML that is returned in the original Response message contains references to additional files. These can and often do include image files that the browser must display, style sheets for formatting, video and audio files that the browser may play, etc. In the web charting application I am using as an example here, the charts themselves are rendered on the server as .jpg image files. The HTML in the original Response message references these image files, which causes the browser to issue additional HTTP GET Requests to retrieve them during the process page composition. Of course, the server-side application builds a .jpg file for each of the two charts that are to be rendered when it builds the original Response message. In order to display presentation-quality charts, the jpg files that are built are rather hefty, given that they must be transferred over the network to the web client. The GET Requests to retrieve these charts fully rendered on the web server in jpg form generate a very large Response message that then requires multiple data packets to be built and transmitted.
So, composing web pages may not only require multiple GET Requests to be issued as a result of <link> tags, Response messages that are larger than the Ethernet MTU require transmission of multiple packets. The number of networking data transmission round trips, then, is a function of both the number of GET Requests and the size of the Response messages. For the sake of completeness, note that whenever the size of a GET Request exceeds the MTU, the GET Request must be broken into multiple packets, too. The most common reason that GET Requests exceed the Ethernet MTU is when large amounts of cookie data need to appended to the Request.
Both the number of files that are requested to render the page and the file size are factors in the YSlow performance rules. For example, the HTML returned in the original Response message generated by the ASP.NET application may reference external style sheets, which are files that contain layout and formatting instructions for the browser to use. Formatting instructions in style sheets can include what borders and margins to wrap around display elements, the size and shape of what fonts to use, what colors to display, etc. The example app does rely on several style sheets, but none of them are very extensive or very large. Still, each separate style sheet file requires a separate GET Request and Response message, and some of the style sheets embedded in the document are large enough to require multiple packets to be transmitted.
Finally, the HTML can reference scripts that need to be loaded and executed when the document is being initially displayed. Scripts that modify the DOM by adding new elements to the page or changing the format of existing elements dynamically are quite common in web applications. Usually written using JavaScript, script code can be embedded within the original HTML, bracketed by <script></script> tags. However, to facilitate sharing common scripts across multiple pages of a web application, JavaScript code to manipulate the DOM can reside in external files, too, that then must be requested and loaded separately.
That is enough about JavaScript for now, but we will soon see that dynamic manipulation of the DOM via the execution of script code running inside the web client, usually in response to user interaction, has the potential to complicate the performance analysis of a web application considerably. It is worth noting, however, that YSlow does not attempt to execute any of the scripts that make up the page. Like the other HTTP objects that are requested, YSlow only catalogs the number of JavaScript files that are requested and their size. It does not even begin to attempt to understand how long any of these scripts might take to execute.
The central point is that page composition and rendering inside the browser frequently requires a series of GET Request and Response messages. The original Response message to a GET Request contains links to additional data files – static images, style sheets, JavaScript files, etc. – that are embedded in the HTML document that was requested. Each additional resource file that is needed to compose the page requires an additional GET Request and a Response Message from the web server. Consequently, the simple depiction of Page Load Time shown in Figure 3 gives way to the more complicated process depicted in Figure 5. When all the resources identified by the web client to compose the page are finally available and processed, the document composition process is complete. At that point, the page load state of the page is finalized, which means it is available to the end user to interact with.
Take a minute to consider all those times that you encounter a web page where the page is partially rendered, but is incomplete and the UI is blocked. The web browser has its instructions to gather all the HTTP objects that the web page references, and you are not able to interact with the page until all the objects referenced in the DOM are resolved. But if the Response message for any one of those objects is delayed, the page is not ready for interaction. That is what Page Load time measures.
Figure 5. Composing web pages usually requires multiple GET Request:Response message sequences due to links to external files embedded in either the original Response message or in subsequent Response messages. It is not until all external references are resolved that the Page can reach its “loaded” state where all the controls available on the page are available to use.
NEXT: Exploring the YSlow scalability model.
[1]
In contrast to the
expert systems approach to AI, which used explicit rules to mimic the
decision-making behavior of experts, machine learning algorithms do not always
need to formulate explicit decision-making rules. The program “learns” through
experience, making adjustments to the decision-making mechanism based on the
success or failure of various trials. The decision-making mechanisms used in
machine learning algorithms vary from Bayesian networks (where explicit
classification rules are encoded) to neural networks to genetic algorithms. The
element that is common in the machine learning approach is a feedback mechanism
from the learning trials. See, for example, Peter Flach, Machine
Learning for more details on the approach.
Comments
Post a Comment