Google Pagespeed 1.1 Scalability with Memory Locking - Web Performance

Google Pagespeed 1.1 Scalability with Memory Locking

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.


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 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:

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.

Michael Czeiszperger
Web Performance, Inc.

Add Your Comment

You must be logged in to post a comment.


Copyright © 2024 Web Performance, Inc.

A Durham web design company


(1) 919-845-7601 9AM-5PM EST

Just complete this form and we will get back to you as soon as possible with a quote. Please note: Technical support questions should be posted to our online support system.

About You
How Many Concurrent Users