In the deployment of a web content management system, scalability can be anything from a nonissue to a major concern.
On most corporate intranets, where as many as 1,000 simultaneous hits are rare, a single Web server running a content management application can easily serve the entire intranet. In such a setting, the capacity of the Web content management application is generally a much smaller concern than its stability.
Scalability is a primary concern, however, when a firm deploys content management on a Web site, particularly an e-commerce site. I have seen several cases where sites either crashed completely or selectively lost content because of problems with their content management systems.
There are several steps site managers can take to ensure that systems scale to meet their needs. The simplest is to install the Web content management application on a different server than the one from which the Web site itself is deployed. Most of the applications tested in a Shoot-Out can be run on a staging server or be configured to export content to an external server.
The benefit of these setups is that the content management is disconnected from the Web site it manages. If the management application crashes, availability of the Web site and its pages would be un affected.
Also, since many content management applications are tied to specific operating systems and Web servers, this approach lets the Web site run on any system and Web server.
Loss of benefits
On the downside, this setup removes many of the potential benefits of a Web content management system. Changes have to be regularly migrated from the server managing content to the server running the site, increasing the need for administrative intervention. This can be especially troublesome for a company specializing in up-to-the-minute delivery of content, such as a news organization.
Running the content management system on a separate server also complicates the process of making quick changes to incorrect content on a site. Corrections either must be delayed until the content management application updates the site or be made outside the content management system.
IPS runs on top of Netscape Communications Corp.’s powerful Netscape Application Server. Through that server, the system maintains load balancing, system failover and session management, ensuring high performance and solid stability.
DynaBase works similarly, but it doesn’t directly use an application server, relying instead on what it calls Web Server Plug-ins. The plug- ins reside on the Web server and communicate with a separate system running DynaBase.
Another option is to scale content management applications by deploying multiple systems and instances of the application. However, content management applications are priced by server and by CPU, so a business could easily spend $500,000-mostly on software licenses-to build a scalable system.
Businesses must evaluate their individual needs for scalability. An intranet crash, while inconvenient, is rarely catastrophic and is almost never caused by high traffic loads. On the other hand, when a Web site goes down, especially an e-commerce site, the company loses money every minute.