This wave of optimizations received some extra funding, which made an enormous difference. I upgraded the underlying virtual hardware beyond a very important threshold at Amazon.
Upgraded EC2 instance type to a level that included "I/O Performance: High".
- While the I/O was a driving force for the upgrade, it also came with 4x CPU and 4x RAM compared to the previous configuration.
- Upgraded to 64-bit architecture and started with a current Ubuntu server template.
- The CPU utilization has dropped to 1/6 of previous levels under normal load.
Upgraded RDS instance class to a level that included "High I/O Capacity".
- While the I/O was a driving force for the upgrade, it also came with 8x CPU and 9x RAM compared to the previous configuration.
- Previously, we would spin a readonly replica during work hours, which means that we are seeing a lower effective increase of about 4x CPU and 4x RAM (since we were doubling up). Of course, those numbers ignore replication and overhead.
- The CPU utilization has dropped below 1/10 of previous levels under normal load.
Reconfigured varnish to use "-s malloc" rather than "-s file" to take advantage of extra RAM now available.
- Cuts disk writes on instance storage to about 1/3 of previous levels.
- Maximizes speed of cached pages.
- Shifted static files into varnish so that static images could be served without hitting the disk at all. Very fast.
Drupal module consolidation.
- Reduced number of modules by upgrading to consolidated versions, disabling less important modules, and consolidating small custom modules that did not need to be distinct (due to low probability of contributing publicly).
- Deleted unused modules from the file system to reduce entries in the system table.
Improved PHP's handling of path resolution based on this post.
Note: It was surprising how much higher than the default (16k) this had to be set to have an impact. 4096k is much higher than we actually utilize, but avoiding a full-cache issue down the line justified the extra high number for us.
Note: This is potentially dangerous when dealing with temporary files. As long as our temporary files rely on tempnam, we should be fine since it makes naming collisions unlikely.
Upgrade EBS for main PHP files to ext4 without journaling
- Saw a 6% reduction in the Write Bandwidth on the device.
- Create a second volume (/dev/xvdm) from an accurate snapshot of the EBS volume (/dev/xvdf).
- service apache2 stop; umount go; mount -o noatime -t ext3 /dev/xvdm /go; service apache2 start
- tune2fs -o journal_data_writeback /dev/xvdf
- tune2fs -O extents,uninit_bg,dir_index /dev/xvdf
- e2fsck -fDC0 /dev/xvdf
- service apache2 stop; umount go; mount -o noatime,data=writeback,commit=100,nouser_xattr -t ext4 /dev/xvd /go; service apache2 start
- Significantly less disk access.
- Faster network communications with database.
- Under normal load, non-cached Drupal pages load at least 10% faster and with less variability.
- Under heavy load, non-cached Drupal pages load more than 50% faster, and the upper limit of supported users is much higher.