Pipelining More Speed

One of the topics I studied when I got my graduate degree was queuing theory. It was a difficult task optimize the serving of customers in a number of scenarios. It is actually more complex than that because these theories can be applied to manufacturing processes as well.

It gets even better now I can apply my training in queues in computer software. You can do this, too!

Traditionally browsers have followed a simple process in retrieving a web page from the server. The server asks for a certain element. After it gets that element, the browser asks for the next element. The process is simple, and in theory should work just fine.

Let's look at a set of log entries for a web page. In Table 6.1 is a typical session to get a page. This session spans a total time of about one second. During this time, a total of six requests were made by the client. This is not an example of a dial-up Internet user with a slow connection; some of those requested objects were large. In fact, the web server received requests to send to this user more than 600KB of information in the span of one second. The time to send this information would be between five and ten seconds.

Table 6.1. Web Page Requests

Time	Command	Size (KB)
23:09:56	GET /photo.htm	12
23:09:56	GET /photogallery/photo26003/MISC4.jpg	142
23:09:57	GET /photogallery/photo26003/mycat.jpg	18
23:09:57	GET /photogallery/photo26003/HMR4.gif	92
23:09:57	GET /photogallery/photo26003/MISC5.jpg	159
23:09:57	GET /photogallery/photo26003/MISC6.jpg	163

But notice what the client did it issued six GET commands prior to receiving the information from the previous GET. This is an example of pipelining by a browser. Multiple requests have been queued and are being responded to by the server.

Is Pipelining the Same As Multiple Connections?

There is a misconception that pipelining opens multiple connections to the web server (though this was true with HTTP 1.0, it changed with HTTP 1.1.) This is not true there is only one connection between the server and the client. What pipelining does is issue multiple requests without waiting for previous requests to complete.

The advantage of pipelining is that the server is better used (the idle time is reduced) because it does not have to wait for a new request when a previous request has been fulfilled. Good? Often times, yes.

However, there is a rub. Some servers have connections or other hardware that cannot handle the number of simultaneous requests pipelining can generate. This results with issues of connectivity and performance that must be addressed.

By default, Firefox has pipelining turned off. Pipelining is configured with the following three preferences, accessible through about:config (see Chapter 9, "Changing Preferences and Settings," for more information about about:config):

• network.http.pipelining This preference is set to false by default. To enable pipelining, set it to true.

• network.http.pipelining.maxrequests By default, maxrequests is set to four. A good number to use is between four and eight. The (undocumented) maximum is eight requests; setting a value greater than eight has no additional effect. This value has no effect if pipelining is not enabled.

• network.http.proxy.pipelining This preference is set to false by default. To enable proxy pipelining, set it to true.

A good document to learn more about pipelining is www.w3.org/Protocols/HTTP/Performance/Pipeline.html. This page gives you background information on the implementation of HTTP pipelining.

A good reference on pipelining in Firefox can be found at the Firefox pipelining FAQ at www.mozilla.org/projects/netlib/http/pipelining-faq.html. Again, if you are interested in pipelining, visit the page.

The Firefox pipelining support is contained in the source folder \mozilla\netwerk\protocol\http\src. Do a search for pipelining in these folders to determine what files are involved in pipelining.

To get the most out of pipelining, a number of other preferences should be tweaked. These tweaks are very effective for users who have a high-speed connection (such as DLS or cable modems):

network.http.max-connections 32 network.http.max-connections-per-server 8 network.http.max-persistent-connections-per-proxy 8 network.http.max-persistent-connections-per-server 4 network.http.pipelining true network.http.pipelining.maxrequests 8 

The first four preferences increase the number of connections for a server. The final two are preferences that tune pipelining. However, on a few websites, this preference setting might provide only a nominal increase in performance, but for most, the differences are very noticeable.

Note

Most of the following preferences are used in nsHTMLContentSink.cpp. This file has some comments that describe the process of drawing content. nsHTMLContentSink.cpp is part of the Firefox source code. See Chapter 18, "Browsing the Code," for information on how to retrieve the Firefox source.

Consider this: Three objects need to be drawn. None of these objects has been fully received, but if the browser waits until each one is fully received, the rendering is much slower. Rather, while waiting, the browser draws what it has, even if it's not complete.