Web Performance Tuning

Architecture Scaling Options

HTTP Is Scalable

Although HTTP is inefficient in the sense that it goes to the trouble of setting up and tearing down a TCP connection for a stateless and generally short transfer of data, HTTP happens to be quite scalable exactly because the connections are stateless and so short-lived. Connections are unlikely to be concurrent with each other because each is so brief, and each connection is likely to have good access to the server’s resources. For example, you probably won’t run out of socket connections, because they’re constantly being closed after use. Since the protocol is stateless, it is entirely transparent to users if some of their requests are fulfilled by one server and some by another. This makes it easy to add more identical servers on the fly to accommodate larger loads in serving static content and is a fundamental advantage of the Web over, say, client-server systems.

CGI scripts, which have been notoriously difficult to scale, can be accommodated reasonably well with the FastCGI protocol, which keeps CGI processes continuously running on multiple machines. See Chapter 15 for details.

Replication and Consistency

Adding identical web servers, however, brings up the question of whether you should replicate your content, that is, whether you should keep multiple copies of the same data or simply partition data across different servers. If you choose to replicate content, then you have the additional burden of keeping that content synchronized ...