Each CMS website will have its own performance and scalability characteristics depending upon factors such as the type of content it is serving, the amount of dynamic data it is serving, the nature of its custom code, and the nature of its users. Red Hat cannot specifically define a guaranteed hardware requirement for a site. However, the following guidelines should prove adequate for typical CMS sites.
The main bottleneck in a CMS installation is the Web server CPU usage. In most cases, adding additional Web servers will increase system throughput linearly. With a well designed caching load balancer, you can use 1U single- or dual-processor rack servers, or take advantage of a blade architecture.
Static content includes assets such as images, binary files (e.g. word processor files, compressed archives), and video. These unchanging items have metadata that is understood and used by the CMS; For example, the CMS manages permissions checking for asset objects. These are perfect items for caching.
Squid can be configured to run on the Web servers, and will cache the site's static content. This content is served directly from the Web server's memory and involves minimal CPU processing. A single typical Web server can serve 100 pages/second with about 15% CPU utilization. Section 1.1 Deploying Squid and Apache for Caching and Acceleration details how to configure this.
For a CMS installation that will only publish static content, a single Web server may suffice for the site's scalability needs. The website's operator may still want to consider adding an additional Web server to increase reliability.
A dynamic page has content that is computed for each request, pulling assets and content, building web applications, then wrapping it all in a user interface. Dynamic pages include the CMS administration pages, pages that require login, and pages with personalized information, such as a portal.
The application servers handle the dynamic content. Because of the computation involved in producing dynamic pages, these servers have a lower throughput for dynamic content. They are also throttled by the database server's ability to answer requests.
It is difficult to calculate what the exact throughput of a page is going to be. It is highly variable and dependant upon the nature of the code producing the page. As a starting point, estimate about 15-20 dynamic-pages/second throughput for each Web server. Your tests in your environment may show different numbers, calling for an increase in application serving power.
To scale very large installations, you can consider moving the application server to one or more separate servers. This will isolate the CPU intensive dynamic page generation from the straight HTTP page serving.