Google Pagespeed 1.1 Scalability with Memory Locking

Add Your Comment
12 December 2012
Posted in Apache-httpd, Performance Reports

In last week’s blog post looking at the overhead of running Google Pagespeed, there was a marked scalability penalty to be paid that was caused by an approximate doubling of CPU load. Several people suggested some options to try, the easiest of which was turning on an experimental memory locking option. (The default mod_pagespeed config uses file locking.) I was also informed as to the plethora of tuning options to tailor the behavior to each site, but decided to keep it simple and experiment with each option separately. As with Apache itself, there’s lots of information about options to change, but relatively few hard measurements as to the effects of those changes. That’s the reason we publish so many research reports showing hard data.

As you’d expect on a virtual OS, turning on the shared memory locking increased the speed of mod_pagespeed. What I didn’t expect to see was to have the average load times decrease under load compared to the baseline. The page load times up to the 500 user level are now nearly identical.

The differences became even more pronounced above the 500 user level, when the pagespeed configuration was better than with mod_pagespeed than without!

The system, as before, was CPU, not bandwidth limited. The interesting thing is that while the average page load time is faster with mod_pagespeed, the CPU usage with the module is still higher than without it. This implies that there would be less CPU available for processing dynamic pages. Apache has never been the fastest web server for static content; there are other programs that do a better job at that task, so next week I’ll take a look at how mod_pagespeed handles dynamic content with PHP, and do a stress test to check for reliability under sustained load.

Conclusions

In the original post I concluded that mod_pagespeed only made sense if your site was lightly loaded. This new result makes installing mod_pagespeed a no-brainer, assuming you first check for compatibility. We’re considering turning on mod_pagespeed for our corporate site, but that will have to wait until we test it with PHP.

Reproducing the Results

The server I used to test was an EC2 m1.large virtual server running Red Hat Enterprise Linux Server release 6.3 (Santiago). The mod_pagespeed module was installed via yum and used version mod-pagespeed-stable.x86_64 1.1.23.2-2258. Apache was configured to use mod_disk_cache and the following pre-fork MPM settings:
StartServers 20 MinSpareServers 25 MaxSpareServers 100 ServerLimit 8192 MaxClients 8192 MaxRequestsPerChild 10000
The test case consisted of these three pages from our site with the PHP removed so that PHP didn’t enter into the performance equation, configured for think times of 4 seconds and connection speeds of 5Mb/s:https://www.webperformance.com https://www.webperformance.com/load-testing-tools https://www.webperformance.com/load-testing-services
Note that I tried to use the worker MPM but could not get it to run with mod_pagespeed without crashes. You’ll want to be sure to apply these ulimit changes as well.