For purposes of understanding the factors that contribute to Web performance, and ultimately to capacity planning, understanding the basic building blocks and activities that together make up a Web transaction is key.
All Web transactions consist of three separate but interlocking sets of activities:
- A client request that initiates activity, and eventually has to handle some kind of response,
- A set of network connections that ferry requests from clients to servers and responses from servers to clients, and
- A Web server that must handle incoming requests, and either provide the requested information, or some kind of alternative response.
In this tip, we'll examine part one, as we explore Web transactions from a client's perspective, from which the components of a typical Web-page request look something like this:
- In a Web browser, or some other kind of Web-enabled application, the client selects a hyperlink to request a specific Web document.
- The browser checks its local cache, and returns that document if it finds a hit therein. This is the best possible case for a page request.
- If the file is not present in the browser's cache, the browser may request a DNS lookup if the address uses a domain name rather than a numeric IP address.
- Once translated, the client opens a TCP connection to the server at the requested IP address.
- When a connection is established, the client sends an HTTP request to the server
- for the required document.
- The server provides some kind of response to the client's HTTP request, which may be anything from a (very brief) error message, to a whole set of files and documents that represent the content.
- The Web browser fields incoming pieces and parts, and composes a Web page, complete with anything from simple text (single document transfer only) to page containing graphics, enriched media, and so forth(multiple document transfer, possible data streams opening and closing, and so forth).
Notice the elements that are involved from the client's perspective, or that are directly under the client's control here. They serve as a client's most fruitful avenues for clearing bottlenecks or achieving performance improvements:
- A faster PC (faster CPU, faster drives, faster displays, more and/or faster memory) provides the kind of performance improvement that benefits all local applications and activities equally.
- Newer, more capable software may be a source of performance degradation or improvement, depending on the exact circumstances involved. In many recent cases, however, Web browsers do seem to demonstrate improved caching and page-access behaviors.
- A faster Internet link (a complex subject of itself, as I'll explain in more detail in a further tip) can provide dramatic performance improvements. This is especially true if a user upgrades from an slower link (such as a POTS link with a modem) to a faster link (such as ISDN, cable modem, or DSL). For users who access a network to get to the Internet, upgrading LAN interfaces and throughput typically produces only modest speed gains at best. Because the link to the Internet is usually slower than 10 Mbps, let alone 100 Mbps or higher, the Internet link becomes a bottleneck rather quickly in such situations.
- General PC performance optimization also confers a "rising tide" effect on performance. For example, for some versions of Windows (pre-2000, including 9x and NT) tuning TCP window size can have dramatic effects on Internet performance, regardless of the speed of the underlying Internet link). Likewise, routine optimizations like disk defragmentation can also improve browser performance (given especially the Web's proclivities to litter hard drives with cookies, temporary files, and other detritus).
But the general impact of performance tuning on the client side is to minimize a relatively small portion of potential causes for delay or performance problems. Typically, improving client performance overall (except possibly for upgrading from a slow telephone line to some faster all-digital technology) will seldom contribute more than a ten per cent overall performance improvement at best. As I'll explain in the 2 following tips, external networks that lead to the Web server, and the Web server itself, contribute a lot more to overall latency than does the client itself.
Ed Tittel presides over LANWrights, Inc., a company that specializes in Web markup languages and tools, with a decidedly Microsoft flavor. He is also a co-author of more than 100 books on a variety of topics, and a regular contributor to numerous TechTarget web sites. Contact Ed via e-mail at firstname.lastname@example.org.
This was first published in May 2002