Unlike a lot of the conversations here, my question is not about a single high-traffic site, but dozens of small to medium traffic sites. I run a small web design company which hosts approx. 50 low-traffic sites on a single dedicated server. We are working to increase this to 100+ in the next year. Some are Drupal 5, but most are Drupal 6. Most sites are also on multi-site configurations, with around 6 different Drupal instances running the 50 sites.
Since configuration for each site needs to be minimal, I'd like to find a solution for optimizing my server that can be applied once and will require minimal configuration for each Drupal site. Any suggestions on what types of global fixes I can apply to my server which will help performance throughout?
Thanks in advance,
Chuck
Comments
Question is to what you want
Question is to what you want to optimize against. It's clear you want to host as many installations as possible on one single server but depending on your hardware and the nature of those sites it might not be possible.
Performance optimization is a seemingly small word for a lot of stuff that may or may not be done. You can start with general stuff like disabling and uninstalling not needed modules, using the standard Drupal optimization stuff (CSS compressing, normal caching, JS compressing in D6). If you develop you customers' themes, you may also be aware of the possibilities to reduce client waiting time and server load by using CSS sprites.
On the server side you have a vast number of configuration parameters which may come into play. What screws to turn how much depends a bit on your iron and the kind of load your pages create. Common sense is, that it's always good to have a fair share of RAM which you can use for different buffers and caches.
Web servers mostly serve files (static files like CSS files, JS files and images). Reading files from disk takes time and the more spreaded thoses files are on disk and the less frequent single files get read and the less spare RAM you have the worse performance might be, as those files may kick each other out of the operating system file cache faster and have to be re-fetched from disk - which is a rather costly operation.
Static file fetching might also interfere with the database if it has to read or write data. So take your time tu fine-tune your database.
Some rules of thumb:
- use a PHP bytecode cache (APC seems to work best, but don't forget to check from time to time if it's cache hit rate is high enough. if not you better increase memory for it)
- with your number of installations, you'd better not let your box handle incoming mail because mail content checking (that's what SpamAssassin does and virus scanners do) is also rather CPU and disk intense
- Use the tuning-primer.sh and similar scripts to help you out with tweaking those various MySQL parameters. It's generally a good thing if your key_buffer is big enough to hold all you tables' key data in RAM.
- Install some monitoring (Munin is quite popular) so you always know about your machine an its services' states. You have to play a bit around to find a balance in web server (apache + php) and database server (MySQL) configuration, as you have to pay attention to how many max instances you configure and how many RAM those instances need in a worst case scenario. Obviously your machine should never ever swap! Once it starts swapping in a kind of digg-effect situation (or after being slashdotted), it'll bring you machine to a halt as even more news requests arrive and spawn new processes (wanting even more RAM) while your box can't serve them because it's busy swapping trying to serve the older requests...
There's sooo much you can do. But mostly it's general server config stuff and not so much Drupal related.
Alex
my experience
i have a similar setup [single server for serveral medium/small sites that I host]. I've blogged here:
http://homeofficekernel.blogspot.com/2008/02/drupal-centos-optimization.html
and
http://homeofficekernel.blogspot.com/2008/07/infrastructure-projects.html
about what I did.
Since then, I've been looking at a couple of more complicated additions including using varnish as a front-end proxy and media mover or other solution to push static files to another server. Specifically - once you've optimized your apache/mysql/php bits that are serving Drupal pages, you'll want to get the non-drupal requests out of that stack, since they're just using up memory and cpu that could otherwise be increasing the amount of traffic on the server.
But the stuff in my two blog postings above are simple things that probably everyone with this kind of setup should do - straightforward. mostly risk-free and with a huge increase in the amount of traffic you can serve. As one last piece of generic advice - other than adding mysql index caches, i'd stay away from doing anything more to mysql - you can spend a lot of time in there and make it worse quite easily. Improvements are hard to measure and may be misleading - on the whole, if you're using Drupal core and well-developed contrib modules, they'll be well optimized, and if most of your traffic is anonymous, mostly irrelevant.