Chapter 27. Running a Busy Site

Tips on growing from a small website

As the chapter on installation requirements explains: There are no specific hardware requirements for a LiveJournal installation, but Apache/mod_perl and MySQL can utilize a lot of memory very quickly. Determining the right amount of processor speed, storage space, and RAM depends on how busy your LiveJournal installation will be. A simple rule of thumb to remember is that posts and comments drive site traffic, not necessarily the presence of more users.

As your site grows, move MySQL onto its own (physical) server. MySQL will benefit from the extra memory, as will Apache/mod_perl.

Consider putting static content, such as images, on a subdomain attached to another server: Look at using a webserver like thttpd[o], lighttpd[o], Perlbal or a minimal Apache setup without mod_perl, (for serving the static content residing on a separate server; LiveJournal requires Apache). There is little benefit in running CPU-expensive mod_perl & Apache processes just for serving images.

If you are not able to do that, tweak your LiveJournal configuration so images are under a different port, like, and run another webserver daemon instance on that port (not just a virtual host inside a <VirtualHost> container, another instance of the Apache daemon — virtual hosts would use mod_perl).

Use appropriate values for Apache directives like MaxRequestsPerChild and MaxClients, based on your hardware and traffic.

Scaling for large sites

Maintaining a busy database-backed website involves more skills than you need if you are running a small installation for development-only or for a small group of friends. You should consider employing a systems administrator to look after the servers. This chapter is intended to point to a few resources for information on running a large, scalable installation.

Brad Fitzpatrick, the original creator of LiveJournal, has given presentations about LiveJournal/ infrastructure and scaling, at technical conferences. You can find slides/other materials on the Danga Interactive[o] website.

You can find information about database master-master cluster replication through a search engine; some introductory information is MySQL Master-Master Replication Tutorial[o].

memcached was created so instead of relying on disk reads which are expensive (slow), the installation could use memory more (cheap, fast). Unsurprisingly, memcached requires memory (RAM). To give you an idea, the amount of RAM available on for memcached was 40GB, in late 2003. The amount of accounts “active in some way” at that time was in excess of 1.9 million, from a total of approximately 4.8 million total accounts. The default memcached setting for maximum amount of memory to use for object storage is 64 megabytes. Smaller needs call for less memory.

Information about memcached is available on the Danga Interactive[o] site.