A Modular Approach to Serving Dynamic Content
By Phil Stevens
Running a complex Web server operation means more than just getting a fast system with lots of disk space and slapping Apache or IIS on it. High-volume sites typically run on parallel server farms or high-availability clusters with features such as database back ends, dynamic pages built from templates and server side includes, and client-state management. When user loads increase, the number of possible tweaks needed to improve site performance can stymie a system administrator's efforts to find a quick fix. A speedy HTTP server can overwhelm a database engine with queries, a round-robin "pseudo cluster" can be crippled by a dead member, or a peak user load may bring an otherwise stable system to its knees.
Throwing more hardware at bottlenecks often yields disappointing returns on the investment involved. For sites with dynamic content, the greatest latency is typically introduced with script execution or server calls to a database, and the subsequent assembly of pages from the resulting record sets. In many instances, these pages look nearly identical for the majority of a site's visitors. Even in cases of personalized content, a typical page that's served will have identical header and footer information. The pieces of its graphical layout are also usually the same, no matter who's receiving them. A caching server can stockpile the most frequently requested pages or components and distribute them more efficiently than a Web server that's also executing CGI scripts, and issuing SQL queries.
I examined two types of caching solutions in an earlier product review ("
|
