Specific server recommendations for the delivery tier and web server

Is there additional recommendations for delivery tier and web server configurations when setting up the CM1 environment. In reviewing ‘CM1 Configuration Best Practices’ I see specific requirement/recommendations for the CM1 server - how about recommendations for the delivery tier and web server?

I am sure others will weigh in on this, but from experience, there are many factors to consider when looking at specs for a production server. The advantage CM1 has, to a decent degree, is the decoupled approach. Because the pages and data are not being compiled or assembled at run time, the load on the production, or live, server is considerably less than on something like a Cold Fusion or .Net powered site.

That said, the primary factor to look at for specs is the load. How many site visitors does you website have on average per day, week, and month? Also, are you running any additional websites or apps alongside the production/live CM1 site? If you have many apps or websites running on the same machine, the requirements will be much greater, again depending on load. I could have 40 websites on one server with low resources because I only get 100 hits a day combined.

The other thing would be the degree of use of dynamic elements in CM1 like auto-lists and other scripts or service calls. When you have an abundance of server calls and requests being made, or large amounts of data being requested for large lists or several lists at once, the server can be taxed more requiring greater hardware to meet the demands.

Another factor commonly overlooked is the size of assets and files in the system. Many times attention is paid to memory and processor size but not hard drive space. If you host a large number of office documents (PDF, DOC, XLS), videos, or downloadable files, these will require more storage on your server.

With these things mentioned, the average small to medium size site can be hosted on 2-4GB of ram depending on OS (Linux or Windows). Additionally, 5-10 GB for the entire website is typically more than sufficient and most modern day processors can handle hosting a website as well. For large sites, or heavily visited sites, 2 servers meeting these criteria in a load balanced configuration will do very well. You could also use a single server with memory bumped up, again depending on load.

As we use Apache Tomcat to host the delivery services, there is a ton of great information out there on capacity planning for the delivery tier. HP has a good sizing guide here.

Tomcat can scale to around 10,000 requests per second on a single server using modern servers and operating systems. That’s a pretty busy web site. So many users will not need to worry about that at all. I would recommend using every 7,500 requests per second as the trigger to add an additional (or remove in the event of a traffic down turn) delivery server to the web tier.

Daved is spot on on the memory for small or medium sites. Especially when using the embedded database in the delivery tier as that shares RAM with the application server. For busier sites I would recommend using one of the other database options like MySQL or SQL Server to offload that disk I/O, processing, and memory to a seperate database server. The embedded database is also single server only, so if you are looking at a web server farm or a load balancer, you know you need a database server as well.

Another good rule of thumb is to use 64-bit operating systems. More memory is available on these systems so you would have the option to expand the RAM available on the delivery server as web site traffic increases. This is especially true with Cloud Hosting providers as often they can just re-size your instance to add more CPU and RAM and your web site takes off in popularity and grows.

It’s always a good idea to have a backup server, especially when using physical hardware and hosting your own web site. Even when not used to balance load, it’s allot easier to repoint traffic to the backup in the event that the primary server fails.

HTTP Accelerators like Varnish or Edge Caching can also help increase server throughput and performance because they cache and serve common or popular requests directly (like that autolist on your home page).

To give a concrete example:

The Helpweb site is currently hosted on a Small server at Amazon with these specs:

1.7 GB memory
1 EC2 Compute Unit (1 virtual core with 1 EC2 Compute Unit)
160 GB instance storage
32-bit or 64-bit platform
I/O Performance: Moderate

I use Varnish as an HTTP Accelerator and NGINX as the web server. Nginx proxies back to Tomcat any delivery requests and Varnish caches results.

The traffic on this site is good, but not millions of hits a day (Yet!) The performance is good, and I have a warm backup ready to take over or turn into a secondary if traffic spikes or the primary fails.


I was thinking “Wow my response is long.” but after this, I feel a bit better. :wink: Very good information here!