Question

What’s the best way (ways?) to speed up a php web site and how much faster it can using this or that way?

Answer 1

PHP isn’t really the kind of language where you can do micro-optimizations, or just work on the code alone. There’s really no point. Although PHP isn’t particularly fast, PHP itself is rarely the bottleneck in a given web site.

You need to work out where that bottleneck is before you can fix it. There are a lot of common bottlenecks, with common solutions. It’s difficult to generalize, given so few details, but there are a lot of performance hints that apply to most web sites.

The first good place to look is actually on the client side, rather than the server side. How large are your pages (including images, CSS, JavaScript and the like)? How many HTTP requests does a single page view require? Use something like Firebug (and the YSlow add-on for Firebug) to see how long your page actually takes to load, and which bits of your page cause the problem. Some general hints:

• Work out ways to shrink the CSS and JavaScript – remove anything you don’t need, and run the rest through a tool like YUI Compressor.
• If you have multiple CSS and JavaScript files, try to combine them into a single file.
• Optimize all of your images as much as possible, and see if you can combine any of those into a single file using CSS sprites or similar. PunyPNG is good for lossless images. A decent JPEG encoder (NOT Photoshop) is good for photos.
• Move the CSS to the top of the page, and the JavaScript to the bottom, so the browser can render the page before the JavaScript has finished downloading.
• Make sure that all of your CSS, JavaScript and HTML are being served compressed.
• Make sure that you’re using appropriate caching – if a file hasn’t changed, there’s no point in re-downloading it.

Once you’ve got the client side out of the way, you might have to turn your attention to the server side.

Install an opcode cache, like APC, XCache, or Zend Optimizer. It’s very easy to do, and will always provide some improvement. Once you’ve done that, profile your pages, to find out where the time is actually being spent.

More likely than not, you’ll be spending most of your time waiting for the database to return results. So, at a bare minimum:

• Work out which queries are taking the longest, and work on them first. Use your head though – a query that takes five seconds on an admin page that nobody looks at is not as important as a query that takes one second on the front page.
• Make sure that your query uses appropriate indexes. No common query should ever need to do a full table scan. Certain kinds of sorting or grouping may be unable to use indexes – try to avoid them, or modify the query so that it can use indexes.
• Make sure that your queries aren’t using temporary tables.
• Use the EXPLAIN keyword – it’s very useful.
• Tune the database server itself. MySQL is generally not optimized for performance.

Once you’ve done that, it’s usually best to start working out how to use caching. The best way to speed PHP code up is to reduce the amount of work it has to do.

• Make sure your database’s query cache is working properly.
• Use something like Memcached to store frequently used results, instead of getting them from the database.
• If you have enough memory, try to keep everything in Memcached, resorting to the database only when something isn’t present in the cache.
• If you have chunks of pages that are dynamic, but the same for all users, try caching those chunks. For example, if two users are looking at an article, the article itself is going to be exactly the same for each user, even if the rest of the page isn’t. Generate the HTML for the article, and chuck it in the cache.
• If you have lots of non-authenticated users, it’s entirely possible that they’ll all be seeing the exact same page. Two non-authenticated users looking at the above article won’t just see an identical article – they’ll see an identical page, right down to the login links. Set your PHP scripts up so you can use HTTP caching headers (check the last modified date, and return a 304 Not Modified if it’s not been changed). Once you’ve done that, stick a Squid reverse-proxy in front of the webserver, and let Squid serve pages out of it’s cache.

After that point, the general approach is to start using more servers, and the problem becomes one of scaling, rather than raw speed. The general plan is to make sure that your website has a shared-nothing architecture – all persistent data is stored in the database. Then, you install multiple webservers, move the database server to a separate machine, and run the entire thing behind a caching reverse proxy. To add more capacity, you add more machines.