Over the next 2 months (or thereabout), expect things to not always work exactly as they may now on my site. Some things unrelated to the actual install of WordPress on my site may be unavailable during this time. I don’t think anyone other than myself uses them, so I think everything should mostly go unnoticed.
I’m going to be performing some shuffling, and hope to keep it as minimally impacting as possible.
If you spot something strange, give me a shout!
Update: The Shadowbox JS plugin is back in the repo!
I was notified on December 28, 2011 that a complaint was made to the WordPress.org plugins repository team that the Shadowbox JS plugin contained non-GPL code (shadowbox.js). This is correct, and I have known about it for some time, and although I had permission from the author to include it in the plugin download, it still doesn’t make it GPL. Due to this, the plugin has been pulled from the WordPress.org Plugins Repository.
It will likely be some time until I can get it back into the repo, as it is going to require some pretty large updates to the plugin to make use of the WP_Filesystem class to ensure that I can have the plugin reliably download the shadowbox files and put them into place so that they can be used.
I could always strip shadowbox out of the plugin, and require users to download and upload manually, but the user experience of doing such would be horrid, and likely cause a lot of users to stop using the plugin.
In the mean time the plugin can be downloaded from http://dl.sivel.net/wordpress/plugin/shadowbox-js.3.0.3.9.zip
If you wish to test out the upcoming version that is addressing the issue of including shadowbox.js to get it back into the repository, you can download it from http://dl.sivel.net/wordpress/plugin/shadowbox-js.3.0.3.10a.zip
This post has been on my mind for quite some time now, ever since I wrote Part 1 over 1 year ago.
Part 1 only really addressed opcode 1 and Object caching 2 and didn’t really touch page caching 3. In this post I have revisited all tests and added in comparisons of using both the APC Object Cache + Batcache plugins as well as using the W3 Total Cache plugin.
For the above stats gathering, with PHP generation time and cURL time to start transfer, 102 sets were collected, the first 2 were dropped due to cache priming, the remaining 100 were used, and averaged. With the Apache Bench tests, 12 sets were used, dropping the highest and lowest value, and averaging across the remaining 10. Include and stat() counts were gathered over 5 sets not requiring averaging as they were the same between runs.
To find the optimal concurrency and req/s for Apache Bench, I performed manual testing, visually inspecting the results until I reached what I classified as a “sweet spot”. Using the “sweet spot” stats, I performed additional sets to gather the averages for requests per second.
I have not compared static file caching yet and hope to compare W3 Total Cache and WP Super Cache in the future. In this comparison I am mainly focusing on opcode, object caching and page caching.
I am going to try to keep this comparison about the stats only, and not make this a critique or review of the plugin, although in some cases this will not be possible.
No opcode and no caching:
PHP Generation Time: 0.13787 seconds
Number of includes: 80
Number of stat calls: 266
cURL time to start transfer: 0.15463 seconds
Apache Bench Concurrency: 15
Apache Bench Requests Per Second: 19.1483 req/s
APC opcode and no caching:
PHP Generation Time: 0.05088 seconds
Number of includes: 80
Number of stat calls: 148
cURL time to start transfer: 0.05673 seconds
Apache Bench Concurrency: 60
Apache Bench Requests Per Second: 68.2636 req/s
APC opcode and APC Object caching:
PHP Generation Time: 0.03407 seconds
Number of includes: 81
Number of stat calls: 148
cURL time to start transfer: 0.03975 seconds
Apache Bench Concurrency: 260
Apache Bench Requests Per Second: 77.7214 req/s
APC opcode and W3TC APC Object caching:
PHP Generation Time: 0.03993 seconds
Number of includes: 102
Number of stat calls: 285
cURL time to start transfer: 0.04591 seconds
Apache Bench Concurrency: 200
Apache Bench Requests Per Second: 67.581 req/s
APC opcode and APC Object and Page caching with Batcache:
PHP Generation Time: N/A
Number of includes: Unable to collect
Number of stat calls: 41
cURL time to start transfer: 0.00316 seconds
Apache Bench Concurrency: 600
Apache Bench Requests Per Second: 147.2156 req/s
APC opcode and W3TC APC Object and Page caching:
PHP Generation Time: N/A
Number of includes: Unable to collect
Number of stat calls: 87
cURL time to start transfer: 0.00625 seconds
Apache Bench Concurrency: 500
Apache Bench Requests Per Second: 147.8425 req/s
I can state the following about just enabling APC in PHP, if you do nothing else, you should at least do this:
I see performance improvements using both APC+Batcache and W3 Total Cache. However, in all tests, APC+Batcache seems to outperform W3 Total Cache, in PHP generation time, number of includes, number of filesystem stat() calls, time to start transfer, number of concurrent requests and requests per second with relation to concurrency.
I was able to push APC+Batcache to 700 concurrent requests, but req/s dropped. W3TC capped out at 500 concurrent requests, and would go no further, however 500 requests per second provided the highest req/s for W3TC.
W3TC does provide a lot of additional functionality to help reduce load on the server, such as tweaking client side caching, and using a CDN, where APC+Batcache does not, although there are small unitasking plugins that can add the missing functionality for you such as:
APC+Batcache consists of adding 3 new files, and no new directories. The W3TC download consists of 60 new directories and 351 files. The directory listing level for W3TC being as deep as it is, 5 levels deep past the directory for the plugin itself, causes a significant increase in filesystem stat() commands.
Most shared hosting providers as well as many multiserver environments will often host their web roots on NFS, and the more filesystem stat() calls, the worse performance you will see, especially under higher load.
Something else to note, is a lot can be done on the server to also improve performance. You can also use caching applications that logically sit in front of the webserver to cache, instead of using caching plugins, which will also improve performance. There are probably eleventy billion ways to improve performance, so if in doubt, consult an expert to help.
Notes:
For some time now I have been wanting to write an up to date XCache object cache plugin for WordPress. Around 4 years ago I did an opcode caching comparison between APC, XCache and eAccelerator. My results had shown that at the time that XCache was the fastest of the 3. Unfortunately I didn’t think to keep that data around. As a result of these tests I had standardized the environment I was working on with XCache, and have never thought twice about it. Since I use XCache for opcode caching everywhere, it seemed like writing such an object cache plugin would be beneficial. After writing the plugin I figured it best to test performance, comparing it to the Memcached object cache and the APC Object cache. I tweeted a lot during my initial testing, and got an overwhelming response to write up a post, and here we are…
I’ll try to make this comparison comprehensive, but it can be a little difficult to always cover everything.
The test environment:
The times are based off of the standard timer_stop() code often found in the footer.php of themes, in this case added using the wp_footer filter through a mu (must use) plugin:
<?php
add_action('wp_footer', 'print_queries', 1000);
function print_queries() {
?>
<!-- <?php echo get_num_queries(); ?> queries. <?php timer_stop(1); ?> seconds. -->
<?php
}
cURL was used to make the HTTP requests and grab the value from the comment created by the above code:
for (( c=1; c<=101; c++ )); do curl -s http://wordpress.trunk/ | grep '</body>' -B 1 | head -1 | awk -F"queries. " '{print $2}' | awk -F" seconds" '{print $1}'; done;
In each data set I gather 101 results and omit result 1 so that we only have results after the initial cache is generated. The tests are only performed on the home page.
The tests:
I didn’t evaluate eAccelerator due to the fact that it isn’t available in the Ubuntu repositories and I did not feel likely compiling…
The results (in seconds):
For a larger view of the spreadsheet above or if you cannot see it, take a look here.
These results are quite interesting and actually shocked me a little bit. The first thing that I found when developing an up to date XCache Object Cache plugin was that it can’t handle objects! So the plugin has to serialize all data when setting, and unserialize when retrieving. This of course is going to add overhead to every operation.
When I first tested the Memcached Object Cache I was surprised at how little it improved speed. It took me about an hour to realize that the comparison of just using Memcached was unfair as it didn’t include any Opcode caching, adding an Opcode cache brings it more in line with what I would expect.
Using an opcode cache improves performance by over 200% on a stock WordPress install without using any object caching. While APC and XCache provided similar results, my tests still show XCache to be ever so slightly faster as an opcode cache.
Where we see the biggest difference between the 3 of these caches when using APC for both opcode and object caching.
Assuming we are using both Opcode and Object caching here are the results from best to worst:
At this point the single largest failure of XCache is it’s inability to store objects, so I am pretty much planning on dropping XCache on my servers in favor of APC, which will be included with PHP as of PHP 6. I would likely still see marginal speed improvements using XCache on sites that I am not using XCache for an object cache, but on those that I am I’ll get much improved performance off of APC or Memcached.
Now why would I want to use APC over Memcached or vice versa? Well, the one thing that Memcached provides that APC doesn’t is the ability to share the cache between servers. In a load balanced multi web server environment, using APC you would be duplicating the cache on all of the servers as APC provides no way to share this data or allow for remote connections. Memcached however, being a PHP independent daemon can be used for pooling resources and allowing remote connections. You also can get more bang for your buck with Memcached in a load balanced multi server environment because of it’s pooling capability. The pooling capability allows you to dedicate say 128MB of RAM to each memcached instance and when pooled together will give you 128MB x N where N is the number of servers in the pool. Anyway, I digress…
In the end, if you have WordPress hosted on a single web server, APC is the way to go. If you are in a multi web server environment, Memcached is the way to go, but remember to install an Opcode cache as well. If you are crazy and just want to use more CPU cycles, XCache is the way to go.
Some of you may be thinking “why would I need an object cache in addition opcode caching, if the results are similar?” Well, under higher load an object cache will respond better than MySQL, even with MySQL caching. In addition, other factors with MySQL can come into play, such as connectivity to the MySQL server. It may be on another server, with not enough memory, slow disks, with an overloaded network, which decreases performance. Any time that an update query is run, MySQL will flush the whole cache. Another benefit, is we are rarely, if ever, going to use the data exactly as it is given to us from the MySQL query. In the end we are going to process the data before displaying, an object cache allows you to store the processed data, rather than the raw data from the query saving CPU cycles required for the processing. Individually these items may not consume much time, but added together and in a more efficient delivery system, this can make a huge difference.
Now for any of you who go run out and install Memcached, if you install version 1.4.x make sure you get at least pecl memcached 2.2.6 or 3.0.4. Memcached made a change that breaks deletes with earlier pecl memcached versions, which adversely affects WordPress.
A few additional things that I have been asked to talk about are using caching with a WordPress Network, output caching with Batcache and query counts. I promise to get to those, but I just wanted to get this out sooner rather than later.
Yo Dawg! We heard you like caching so we put a cache in your cache, so you can optimize while you optimize…Sorry couldn’t resist.
This past weekend I spoke at WordCamp NYC about Building a High Performance WordPress Environment in a panel presentation with Scott Taylor
The slides for my portion of the presentation can be found at SlideShare and…well…right here:
It’s that time of the year again and my favorite WordCamp is about to begin. Last year I made the trip to WordCamp NYC and spoke in two sessions. I had an immense amount of fun last year, and even though I have moved from the East Coast to Texas I couldn’t pass up the opportunity to attend again.
The company that I now work for, Rackspace, who is a big supporter of WordPress will be sponsoring the event as well as sending myself and Rob Taylor.
As with last year I will be speaking, this time about Performance and Optimization. The Performance and Optimization session will be a panel with myself and Scott Taylor. I will be focusing on “Building a High Performance WordPress Environment” and Scott will be focusing on “Front End Optimization Tools”. If we are able to get a third person on board they will be covering “CDNs and Offloading”. We will be keeping the presentations short to allow time for a question and answer session as well as some discussions between the panel members about certain aspects of performance and optimization in WordPress.
WordCamp NYC will also be holding a Genius Bar as does every other WordCamp, but the one thing most other WordCamps don’t have is me. One other special event happening at WordCamp NYC is the Hacker Room, where myself, Andrew Nacin, Daryl Koopersmith and other WordPress core contributors will be spending time over the 2 day event to write patches for WordPress 3.1 which is just about to hit feature freeze. If you are interested in helping out and getting started with WordPress core development please stop by.
Nearly 2 years ago I wrote a one liner for someone in the WordPress IRC channel to change the author permalink structure. At the time I had not taken the time to really understand WP_Rewrite and as such didn’t understand the implications of flushing the rewrite rules on each page load.
It is sufficient to say that since then, I have taken the time to understand it better and I am fully aware of the negative implications of performing flushes every time someone hits your site. For one thing the default behavior of flush_rules() is to also update the .htaccess file as well as updating the serialized array in your wp_options table that contain the internal WordPress rewrites. Assuming you are using a nasty permalink structure that starts with something like %category% or %postname% that serialized array can grow exponentially with the number of pages you have 1.
To make a long story sort, I have known that I should have changed the code for almost as long as the post has been published, but I was too lazy to do anything about it. It took a few carefully placed pokes and prods to get me moving, and as such I have updated the post to reflect the removal of using flush_rules().
Notes:
Some times I like to look at metrics. Because I am bored? Probably. Without metrics how can really compare things. In any case I wanted to see the difference in the number of queries, generation time and peak memory usage between WordPress 2.9.2 and WordPress 3.0.
One of the things that I have heard people say since the release of WordPress 3.0 is that it is noticably faster. “Is it really?”, I asked myself. No, not out loud…or was it? Generally as much as we would like to make things faster from one release to the next, it doesn’t really happen that way. There are new features added, rewrites of code, a new default theme and in the end metrics change.
So what really changed in the way of these 3 aspects of number of queries, generation time and peak memory usage?
I have provided results as well for Twenty Ten, but so that we can perform a more apples to apples comparison we will use Kubrick. We have reduced the number of queries by 2 from 2.9.2 to 3.0, but it took 0.036 seconds longer to generate the page. In addition we now consume 2.4 MB more memory to generate the output.
I used the following code, placed at the very end of footer.php of the default theme for 2.9.2 and the very bottom of footer.php in twentyten. In 2.9.2 I removed the timer_stop line that already existed in the footer.php of the default theme.
<!--
<?php echo get_num_queries(); ?> queries
<?php timer_stop(1); ?> seconds
<?php echo round(memory_get_peak_usage() / 1024 / 1024, 3); ?> MB Peak Memory Used
-->
The testing set up:
Anyway, not really the most comprehensive metrics gathering test, but just something to look at. But in the end, is WordPress 3.0 any faster? With an absolute default install, no. Does it matter that 3.0 is ever so slightly slower? No. Should I be running WordPress 3.0 now? Yes!
Hopefully you find this post useful and that I didn’t waste 15 minutes of my day that I will never get back to talk about something you could care less about.
Recently I have been getting a lot of questions about how to use a MySQL socket in place of the DB_HOST constant for WordPress in the WordPress IRC channel.
Fortunately this is pretty easy, unfortunately if you are using the web based installer you cannot specify a socket in the “Database Host” field. However, you can do things the manual way and copy wp-config-sample.php to wp-config.php and go that route.
The first thing you need to do is determine the path to the MySQL socket. By inspecting my.cnf you would need to look for something that looks like:
socket = /var/run/mysqld/mysqld.sock
If you don’t have access to look at my.cnf you can try to run the following MySQL query:
SHOW VARIABLES LIKE 'socket';
Now crack open your wp-config.php file and set DB_HOST to ‘:/path/to/mysql.sock’. Take careful note of the ‘:’ (colon) preceding the path. In my example the define for the DB_HOST looks like:
define('DB_HOST', ':/var/run/mysqld/mysqld.sock');
Normally I start these posts with “Every so often someone asks a question in the WordPress IRC channel that sparks my interest”, however today, to my great surprise someone actually caught my attention on the wp-hackers mailing list.
For those of you who didn’t click through, the question was:
Couldn’t find this on forums or anywhere else.
What can I test to check if wp_footer was placed on the theme?
Before any replies came in I was already interested and when Peter Westwood replied with “The other way to do it is to do a http request based test which a special query arg on which you output a string on wp_footer.“, I was on the hook.
I spent a few minutes writing up a test plugin, to perform only this functionality and responded back to the list. It was pretty well accepted and I got a few comments from Ozh and Andrew Nacin on Twitter. One of the comments was actually an idea, to extend the checks to make sure that the calls to <?php wp_head(); ?> and
<?php wp_footer(); ?> were in the proper places in the code.
Before I get to the code, I want to spend a little time talking about the significance of wp_head() and wp_footer(). These 2 functions are the key to functionality of a lot of plugins and are the real work horses of themes. The wp_head and wp_footer functions allow WordPress core and plugins to hook into your theme either directly before the </head> or </body> html tags in your theme and perform actions. The majority of the time these actions are used to output style sheets or JavaScript, for use by plugins. WordPress core uses it to output a lot of good functionality such as relational links to your RSS and ATOM feeds into the head of the document. Joseph Scott wrote about this nearly a year ago. His post is fairly short but does a good job at explaining why it is important to include these functions.
Back to the original discussion, which was how do we detect whether or not wp_head and wp_footer are called in the active theme, and if called are they called, was it from the proper locations?
In my proof of concept plugin, we hook into admin_init, which will actually use wp_remote_get() to retrieve the frontend of our WordPress site. It calls the url with 2 query vars, that if present will cause the plugin to hook into wp_head and wp_footer and output some content that we will later look for. If the response was successful, as in returning a 200 response code, we will look at the content to see if <!--wp_head--> and
<!--wp_footer--> are present. If they are not we will see an admin notice telling us which problems were found. If those strings were found but they were not found directly before
</head> or </body> the notice will alert you of such.
Without further adieu:
Just in case you cannot see the code above, use this link: http://paste.sivel.net/24.