Over the next month or so, we’ll be upgrading the POP and IMAP software we use for e-mail mailboxes. We don’t expect customers to notice any change (except possibly improved speed) or experience any service interruption at all; we’re mentioning it just for completeness.
WordPress installations handle missing image files very inefficiently by default, running the entire WordPress script to build a custom “404 Page Not Found” page rather than simply letting Apache return an immediate default “404” response. Running the WordPress script when not necessary is a huge waste of processor time. For example, WordPress might be able to only process 8 requests per second for a missing image when WordPress generates a custom “404” page, but Apache can return process over 1,000 raw “404” responses per second. If your Web site contains references to missing files, this default WordPress behavior can be driving up your CPU usage unnecessarily. We’ve seen poorly-configured Web sites spend a significant portion of their CPU time processing missing images.
In a previous post, we talked about how increasing the WP Super Cache “Expire time” from 1 hour to 48 hours can help the performance of WordPress blogs.
Here’s another tip that can help dramatically: Remove “bot”, “ia_archive”, “slurp”, “crawl”, “spider” and “Yandex” from the Rejected User Agents box in the WP Super Cache plugin settings. (In most cases, this will leave the box completely empty.)
We keep coming across WordPress customer sites that have hurt their performance by switching from the “WP Super Cache” plugin we recommend to a newer plugin named “W3 Total Cache”. Unfortunately, their site often ends up being far slower after switching to W3 Total Cache.
If you care about the performance of your site, please stick with WP Super Cache unless you have a very good reason to switch. It works, and it works well.
Some people tell us that W3 Total Cache works just as well if it’s properly configured, and they may well be right — but it seems like it’s difficult to configure properly. Our experience is showing that it’s easy to get wrong, and performance ends up suffering. WP Super Cache makes it easy to get great performance.
Many Web sites write data to a database. Usually, the data absolutely must be properly saved, so the default way of adding records (using an SQL “INSERT” statement) ensures that the data is permanently stored on the server’s disks. Doing that takes a relatively long time in computer terms — it’s much slower than most things computers do.
In some cases, you might be storing data that’s not quite so important. And if it means your application can run much faster, you might be willing to risk a very small chance of data loss. That’s where MySQL’s “INSERT DELAYED” statement, which works with MyISAM table types (but not InnoDB tables), can be useful. (Tables are created as type MyISAM by default, so most tables are eligible to benefit from this tip.)
If you use the WP Super Cache WordPress plugin (and you should, if you use WordPress), it has a settings page section titled “Expiry Time & Garbage Collection”. It sets the “Cache Timeout” to 3600 seconds by default, and warns that you should set it lower on a busy site.
That advice makes sense if you have a sudden surge of traffic to a single page. However, if your site is generally very busy across all pages (for example, if you have an archive of hundreds or thousands of posts that are constantly being indexed by search engines), we’ve found that you should do the opposite to improve performance: set it much higher. We recommend setting it to 172800 seconds (which is 48 hours). This can cut your CPU usage in half, which will speed up your site.
