Those who read the shmups forum regularly will know that recently it was time to migrate the service back to the physical server, and since the hardware was getting quite old and not really performing for the price anymore, I posted a donation drive to buy a new one.<\/p>\n
Since the migration, several people have remarked on the response speed of the site, so I thought it’s about time I spilled the information on how everything was configured and tuned.<\/p>\n
Hardware<\/strong><\/span><\/p>\n The donations were enough for me to jump from a HP DL360 G4 up to a much newer G6 model.\u00a0 Not only do these have faster memory and newer CPUs, but they use a lot less power – and that reduces the hosting bill too.\u00a0 It came fitted with a pair of quad-core L series CPUs, these are the low power use CPUs clocked at about 2.2ghz.\u00a0 Since it’s primarily a webserver, I turned on Hyperthreading which presents the OS with 16 logical CPUs.\u00a0 It was loaded with 32GB of RAM, which for reliability I configured in mirroring mode, which presents the OS with 16GB.\u00a0 It also came with four 146GB SAS disks and the battery backed RAID cache module which significantly improves read\/write speeds – I configured those as a RAID 10 set for speed and reliability at the expense of capacity.<\/p>\n Operating System<\/span><\/strong><\/p>\n The operating system picked this time around was CentOS 6, primarily because of the long lifetime of the distribution in terms of patching support.\u00a0 Over time it will become somewhat out of date, but reliability and security are key for internet facing machines.\u00a0 In terms of performance in this area, I went for two main things.<\/p>\n Firstly, even now it’s true that disks have better access times at the start of the disk, so it’s ideal to get the core of the OS (and virtual memory if you expect to use it frequently) close to the start.\u00a0 I wanted to use the Linux LVM, and you can create linear volumes rather than have the data scattered across the disk, but I wanted to create volume groups with a bit of space to grow specific but related filesystems.\u00a0 I also wanted to have a space for backups right at the end since that area is slowest.\u00a0 For these reasons, I created four physical partitions on the RAID 10 device, a tiny one for the boot partition, a small one for the core OS filesystems in a LVM volume group, a much larger one for the commonly read\/written data (basically all the websites) with a bunch of empty space to extend later if needed also in a volume group, and finally an archive partition for the backups.<\/p>\n The second step was to tune the kernel TCP stack a little – I’m not sure these are the final settings yet as it’s still early days, they’re a little wasteful but on the other hand even the 16GB presented to the OS is much more than we will ever need, so I was free to really throw it around.<\/p>\n Apache<\/strong><\/span><\/p>\n Obviously we’re using Apache as the webserver software.\u00a0 There are more optimised solutions but honestly there’s a reason Apache keeps staying at the top.\u00a0 It’s decently fast, it’s very powerful and flexible and it has a lot of module support.\u00a0 Out of the box most servers are configured pretty poorly – here are some things you need to do, to get the best out of it:<\/p>\n PHP<\/strong><\/span><\/p>\n PHP itself comes pretty much ready to go out of the box in terms of performance, aside from one rather big thing.\u00a0 Using an opcode cache will dramatically increase the speed of any PHP based application you’re running, which includes of course PHPBB.\u00a0\u00a0 CentOS comes with an installable package for APC (it’s bundled with newer PHP versions too), and it installs a config file as \/etc\/php.d\/apc.ini, which looks like this now (relevant parts only):<\/p>\n You’ll want to make sure the management tool (apc.php) is available on your webserver somewhere, in there you can see how much of your cache RAM is in use. In an ideal world you will have enough memory to allocate slightly more than every PHP script on your server requires. Ours does, and the cache hit rate holds at 100%.<\/p>\n MySQL<\/strong><\/span><\/p>\n It’s also worth tuning MySQL, this is your database backend after all.\u00a0 The settings you need here will very much depend on your database size and combination of sites on your host.\u00a0 Essentially you want to try to reduce or eliminate the use of on-disk temporary tables, keep as much of the key index in RAM as possible, and use a sensible amount of query cacheing.\u00a0 There is an excellent tool which can help you, called mysqltuner.\u00a0 Run it after your server has been in service for a week or so and it will recommend tuning settings, repeat this process.\u00a0 Based on my own knowledge and recommendations from that tool, the relevant part of our config now looks like this (note we don’t use InnoDB tables so don’t need the support, and use local UNIX sockets rather than TCP based connections):<\/p>\n PHPBB<\/strong><\/span><\/p>\n There are a few tweaks we can do with PHPBB too.\u00a0 Firstly, we can tell it to use APC to cache templates instead of disk.\u00a0 In your config.php, include the line:<\/p>\n Secondly, you should tune your actual page code – for example inlining small snippets of CSS code instead of including them – this means less items blocking the page display until loading has completed.\u00a0 Make sure your images are all compressed, try not to include off-site assets – for example our Paypal donate button is actually served locally instead of from Paypal’s servers, thus is just gets hoovered up in the Keepalive session along with the other components resulting in fewer calls (HTTP and DNS) for the client.<\/p>\n Final checks<\/strong><\/span><\/p>\n Google do a very good page analyser which will highlight lots of faults in your code or the way the content is served, you can find it here:<\/p>\n# TCP tuning\r\nnet.core.rmem_max = 512000\r\nnet.core.rmem_default = 512000\r\nnet.core.wmem_max = 512000\r\nnet.core.wmem_default = 512000\r\nnet.ipv4.tcp_rmem = 4096 87380 16777216\r\nnet.ipv4.tcp_wmem = 4096 65536 16777216<\/pre>\n
\n
KeepAlive On\r\nMaxKeepAliveRequests 1000\r\nKeepAliveTimeout 15<\/pre>\n<\/li>\n
StartServers 64\r\nMinSpareServers 10\r\nMaxSpareServers 64\r\nServerLimit 256\r\nMaxClients 256\r\nMaxRequestsPerChild 4000<\/pre>\n<\/li>\n
HostnameLookups Off<\/pre>\n<\/li>\n
<Location \/server-status>\r\n SetHandler server-status\r\n Order deny,allow\r\n Deny from all\r\n Allow from 127.0.0.1\r\n<\/Location><\/pre>\n<\/li>\n
ExpiresActive On\r\nExpiresByType image\/gif \"access plus 1 month 15 days 2 hours\"\r\nExpiresByType image\/png \"access plus 1 month 15 days 2 hours\"\r\nExpiresByType image\/jpg \"access plus 1 month 15 days 2 hours\"\r\nExpiresByType image\/jpeg \"access plus 1 month 15 days 2 hours\"\r\nExpiresByType text\/html \"access plus 30 seconds\"<\/pre>\n<\/li>\n
SetOutputFilter DEFLATE\r\nSetEnvIfNoCase Request_URI \\.(?:rar|zip|gz|tgz|pdf)$ no-gzip dont-vary\r\nHeader append Vary User-Agent<\/pre>\n<\/li>\n
# 480 weeks\r\n<FilesMatch \"\\.(ico|pdf|flv|jpg|jpeg|png|gif|css|js|swf)$\">\r\n Header set Cache-Control \"max-age=290304000, public\"\r\n<\/FilesMatch>\r\n\r\n# 2 DAYS\r\n<FilesMatch \"\\.(xml|txt)$\">\r\n Header set Cache-Control \"max-age=172800, public, must-revalidate\"\r\n<\/FilesMatch>\r\n\r\n# 2 HOURS\r\n<FilesMatch \"\\.(html|htm)$\">\r\n Header set Cache-Control \"max-age=7200, |must-revalidate\"\r\n<\/FilesMatch><\/pre>\n<\/li>\n<\/ul>\n
extension = apc.so\r\napc.enabled=1\r\napc.shm_segments=1\r\napc.shm_size=128M\r\napc.num_files_hint=1024\r\napc.user_entries_hint=4096\r\napc.ttl=7200\r\napc.use_request_time=1\r\napc.user_ttl=7200\r\napc.gc_ttl=3600\r\napc.cache_by_default=1\r\napc.max_file_size=1M\r\napc.stat=1\r\napc.stat_ctime=0\r\napc.canonicalize=0\r\napc.write_lock=1<\/pre>\n
skip-networking\r\nskip-innodb\r\nquery_cache_size=48M\r\nthread_cache_size=4\r\ntable_cache=1024\r\nkey_buffer_size=2G\r\nmax_connections=256<\/pre>\n
$acm_type = 'apc';<\/pre>\n