New mod_pagespeed Apache module to optimize performance

Walter

Walter

Well-known member
Google has released mod_pagespeed, an open-source Apache module that automatically optimizes web pages and resources on them: images, CSS, JavaScript

To view this content we will need your consent to set third party cookies.
For more detailed information, see our cookies page.
!

Currently its available for CentOS/Fedora and Debian/Ubuntu.

Haven't tried it yet but it looks promising.
 
Unfortunately we are on a managed server and have to wait until the hoster adds that mod.
Is anything known about how this 1.0 release will affect server cpu? Betaversions were said to consume 2-3 times more server cpu.
 
IIRC it's been around for a while and when I was on IP.Board the IPS team tested it and found it didn't meet expectations.

I'd be interested to hear from anyone who does try it to know whether it improved performance in page delivery?
 
Been using it on my wordpress site for about 6 months now. I haven't really seen any performance improvements from it at all.
 
I got 92 points at google page for my xenforo start page with advertisements enabled. If you have optimized your web presence, then mod_pagespeed doesnt have much to do.
 
You basically don't need this if a web application is well designed and well written (with good performance in mind). If you don't see much (or any gain) from using it, you probably are already well optimized :)

Some tips to get good page speed scores:
  • Use CSS sprites whenever/wherever you can. Always (unless, it's impossible for some reason). Reducing the number of requests on a page will give you the highest gain. Yes, it can be quite some work to convert to sprites, so don't be lazy, it pays off as your pages will not only load faster but also use less bandwidth.
  • Review your server configuration and implement proper expiration times for static content (scripts, images, style sheets) so that browsers will cache them. Google's pagespeed carefully looks at these things. If you can, serve static content through an extra, lightweight web server (nginx is excellent for this).
  • Load scripts asynchronously when possible. That's even better than loading them at the bottom of the page.
  • For PHP, use a opcode cache, preferably XCache (it's faster than APC), but APC will do the job just equally well.
  • Optimize MySQL. A query cache can help tremendously, but care must be taken to not "overoptimize" it - if a query cache uses too much memory, it can quickly negate the performance effect into a loss :)
 
Do you have some good links about tuning mysql, SilverCircle ? I've MariaDB 5.5 on a VPS with 512Mb and I'm searching how I could optimize memory.
 
SilverCircle said:
Optimize MySQL. A query cache can help tremendously, but care must be taken to not "overoptimize" it - if a query cache uses too much memory, it can quickly negate the performance effect into a loss :)
Click to expand...
I thought that as of 5.5, the suggestion was to not use query cache at all and thus avoid the single mutex? IIRC, since 5.5, the default is 0 or OFF: https://dev.mysql.com/doc/refman/5.5/en/query-cache-configuration.html
If query_cache_size is 0, you should also set query_cache_type variable to 0. In this case, the server does not acquire the query cache mutex at all, which means that the query cache cannot be enabled at runtime and there is reduced overhead in query execution.
Click to expand...
Anyone have any more info on this?
 
Tried by curiosity to disable query cache, and indeed page load is faster and the whole forum seems to be more reactive now. (y)
 
melbo said:
I thought that as of 5.5, the suggestion was to not use query cache at all and thus avoid the single mutex? IIRC, since 5.5, the default is 0 or OFF: https://dev.mysql.com/doc/refman/5.5/en/query-cache-configuration.html
Click to expand...
Well, not everyone is on 5.5 and the suggestion is valid for cases where a query cache would *not* help at all. In that case, you can speed up MySQL a tiny bit more by completely disabling the query cache at startup time.

That doesn't mean a query cache is totally useless. It can still help, but it depends on the application and server environment. For example, if you have only one CPU (core) available, the locking is not going to hurt a lot, because your threads will never execute concurrently.

The real pain with the query cache comes from query_cache_wlock_invalidate=ON because this will result in much more aggressive locking by the cache. The setting is, however, only needed if you *have* to prevent clients from getting results from a table that is currently *write* locked. If the setting is ON, the query cache is invalidated as soon as a table gets write locked (obviously something that can significantly reduce the efficiency of the cache). If the setting is OFF, that doesn't happen and a client could still get a result from a write locked table (if such a result can be found in the query cache). This is something that can bite you if your application must ensure data consistency at all costs - something that is generally not needed for a blog or forum.
 
I've also read on the documentation that you don't need to enable query cache if memcache(d) is installed. Any thoughts on that ?
 
Arkshine said:
I've also read on the documentation that you don't need to enable query cache if memcache(d) is installed. Any thoughts on that ?
Click to expand...
Two completely different pair of shoes, but if an application cleverly uses its own caching (memchached/xcache/apc/whatever) to cache query results, it can help a lot, yes. Fetching a serialized query result from from memcached is almost always much faster than fetching it from the db even if the query was cached by the database server.
 
Thanks for the useful answer. Too bad you don't offer some service to help to configure properly a server, you seem to have a lot knowledge, and I would use it for sure. :p
 
Back
Top Bottom