 |  |
Chapter 20. Web Performance
Contents:
Client-Side Performance
HTML Authoring
Programming
Administration
Using Analysis.cgi to Find A Bottleneck
Monitoring Web Performance Using Perl
Sometimes it seems that no matter how fast your web site is, it's never fast enough. Pages don't load quickly enough, scripts always seem to take forever, and streaming video or audio brings everything to a standstill. The slower things are, the more likely it is that a user will become frustrated and give up. Improving web performance is a constant struggle for every webmaster.
In this chapter, we look at techniques to improve web performance from several different perspectives. Users can upgrade software or hardware, tweak some settings on their browser, or choose a faster modem or ISP. HTML authors can reduce the size of the content being transmitted. Programmers can do quite a bit to improve the execution of CGI programs or other scripts. Most importantly, administrators can reconfigure server software or their website design to greatly reduce the load. Most of this chapter concentrates on the administrator's role in improving performance.
This chapter gives only a brief discussion of web performance and how to improve it. See Web Performance Tuning by Patrick Killelea (O'Reilly) for a more thorough discussion.
20.1. Client-Side Performance
As a user, your ability to improve web performance is limited by the choices others have made about content, programming, and administration. A slow web site is not going to be fast no matter what client accesses it. Still, there are some things you can do to improve your overall experience.
20.1.1. Memory
If you have the money to improve your hardware, buy more memory rather than a machine with a faster CPU. Having the latest CPU will not make as much difference as having a lot of memory. These days, "a lot of memory" means 256 MB or 512 MB.
20.1.2. MTU Size
If you're more ambitious (or don't have a lot of money to throw away on hardware), another potential way to increase browser performance is to tune your MTU size. This can make a big difference if your current MTU is wrong for your connection to your ISP.
MTU stands for "Maximum Transmission Unit," which is the largest packet your PC will send out. You want it to be big enough to carry as much as the other end will accept, but not too big, or your performance will suffer when the other side keeps rejecting packets and telling your PC to send smaller ones. You can use one of the many MTU tuners on the market such as PPP Boost, MTU-speed pro, NetMedic, and Vital Signs.
You can manually figure out your optimum MTU from a Linux machine using the ping command:
% ping -M do -s 1500 www.myISP.com
From a Windows machine, use the following command from the DOS prompt:
C:\>ping -f -l 1500 www.myISP.com
(Use your own ISP's web site in place of www.myISP.com.)
A value of 1500 bytes may get you an error like "Packet needs to be fragmented, but DF set." Keep reducing the value until the ping works; this gives you the optimum value for your MTU.
How you set the MTU depends on the operating system. See http://www.sysopt.com/maxmtu.html for additional information on setting MTUs under Windows. On Linux, you can modify your MTU like this:
# /sbin/ifconfig eth0 mtu 1500
You can get the source code for a version of traceroute that finds MTUs along a route from the code published with Richard Stevens' book TCP/IP Illustrated, Vol 1 (Addison-Wesley). The code is available at ftp://ftp.uu.net/published/books/stevens.tcpipiv1.tar.Z. Use the modified traceroute program to learn about the MTU between yourself and points you commonly visit. On an Ethernet LAN, the MTU is generally set to be 1500 bytes, and this is the way many clients such as Windows 95 are configured by default; but on the Internet you sometimes get better performance if you set the MTU to 576.
20.1.3. Switching Proxies
For those of you that use a proxy to get to the Internet, it pays to try out different proxies. Sometimes one proxy is much faster than others, and there is no automated way to get your browser to pick the fastest proxy.
You have to get a list of proxies to manually try them all out. Your system administrator should have the list of proxies, but if not, you may find their names yourself by examining the proxy.pac file that institutions often use to automatically configure browsers. If your browser was automatically configured via a URL such as http://config.myinstitution.com/proxy.pac, you will not be able to view that URL in the browser. Here is a simple way to retrieve the proxy.pac file via telnet:
% telnet config.myinstitution.com 80
Trying 192.1.14.53...
Connected to www.myinstitution.edu.
Escape character is '^]'
GET /proxy.pac HTTP/1.0
HTTP/1.1 200 OK
Date:
Sun, 08 Feb 1998 18:35:25 GMT
Server: Apache/1.2.5
...
(institution's proxy servers will be listed in body of response)Rather than manually trying out each proxy, you may be able to figure out which one is least loaded by using the rstat program. rstat will report load statistics for any machine running the rstatd daemon, which Solaris, AIX, and Linux machines run by default. It doesn't hurt the proxy to try using rstat on it, and rstat is freely available from http://patrick.net/software/rstat/rstat.html.
20.1.4. Do You Have a Faulty DNS Library?
A last client side tip, for advanced Linux users: recent versions of the resolver DNS library that ships with RedHat Linux have a serious bug. The library will do DNS lookups for absolutely every machine name or address you surf, even names listed in /etc/hosts, and even plain IP addresses. This happens regardless of how /etc/nsswitch.conf is set. This will slow down your surfing of sites named by IP address, or machines you list in /etc/hosts that do not have a DNS entry. As a fix, either downgrade your version of libresolv, or complain to RedHat.
|  | |
| 19.38. mod_vhost_alias |  | 20.2. HTML Authoring |
Copyright © 2003 O'Reilly & Associates. All rights reserved.