Skip to a section of this page:

Ramblings

Archive

WordPress performance revisited

December 6th, 2009

Stefano asked if I had numbers to back up my previous performance claims regarding WordPress performance plugins. Today I ran some tests to be able to provide those numbers.

All tests were performed:

Results

The “baseline” results represent tests without DB Cache Reloaded, Hyper Cache, or GZIP Output plugins installed. Different combinations of these plugins were then tested. Each combination was tested 10 times and the results have been averaged.

This site (irama.org) — number of seconds to render HTML of the homepage
test baseline DB Cache Reloaded Hyper Cache DB Cache Reloaded + Hyper Cache DB Cache Reloaded + GZIP Output
1 0.325 0.294 0.299 0.409 0.292
2 0.458 0.447 0.322 0.318 0.335
3 0.366 0.267 0.493 0.290 0.313
4 0.287 0.299 0.765 0.331 0.269
5 0.740 0.319 0.393 0.311 0.512
6 0.807 0.276 0.315 0.435 0.354
7 0.351 0.270 0.348 0.280 0.343
8 0.347 0.403 0.361 0.292 0.290
9 0.412 0.298 0.321 0.336 0.263
10 0.418 0.263 0.286 0.364 0.267
Avg. 0.451 0.314 0.390 0.337 0.324
A more complex client site — number of seconds to render HTML of the homepage
test baseline DB Cache Reloaded Hyper Cache DB Cache Reloaded + Hyper Cache DB Cache Reloaded + GZIP Output
1 3.116 2.477 2.198 2.287 2.693
2 2.663 0.749 2.542 0.712 0.895
3 2.820 1.008 2.382 1.143 1.221
4 2.390 0.799 2.501 0.827 0.880
5 2.304 0.758 2.581 0.939 0.939
6 3.348 0.795 2.364 1.068 1.109
7 3.150 0.866 2.248 2.483 1.172
8 3.139 0.989 2.512 1.125 0.912
9 3.115 0.789 2.667 0.939 1.092
10 2.525 0.776 2.306 2.613 0.910
Avg. 2.857 1.001 2.430 1.414 1.182

Analysis

My previous recommendation of Hyper Cache was primarily because it provides GZIP compressed HTML. Since the results for DB Cache Reloaded + Hyper Cache were not as strong as DB Cache Reloaded alone, I looked for an alternative plugin that might provide GZIP compression without as much of a page render performance cost.

I tested the GZIP Output plugin, and while it still seems to negatively impact on page render time, I believe the addition of GZIP compression — which will lower the size of the transmitted HTML file — is worth the small hit on render performance.

Note: If your web server compresses HTML output from PHP files automatically (or it can be configured to do so) then use that approach instead of using the GZIP Output plugin as it is likely to perform slightly better. The other benefit of this approach is that compression will also be applied to the HTML output of PHP files that are not part of WordPress (if you have any).

Conclusion

In terms of performance (on a shared hosting environment) disk IO is expensive, but DB access is more expensive. So while Hyper Cache alone makes a difference, DB Cache Reloaded makes a greater difference. YMMV, but in light of this data, I would update my recommendation…

For best WordPress performance, use the following plugins:

  1. DB Cache Reloaded
  2. WP Minify
  3. GZIP Output (only if your web server doesn’t GZIP HTML output from PHP automatically).

Note: If DB Cache Reloaded is not an option with your hosting provider, or you aren’t able to get it working, Hyper Cache is still a good option (remember: you won’t need GZIP Output if you have Hyper Cache installed).

Finally…

I hope this helps. Let me know if you have feedback about my methods/results, or if you have other WordPress performance tips.

Posted in
Wordpress
Tools
No Comments

WordPress performance

December 4th, 2009

Update 5 December 2009: Recommendation revised based on new data.

As promised, here’s a quick rundown of the WordPress performance plugins I’ve been using.

  • DB Cache Reloaded = Big performance wins. Especially on shared hosting.
  • Hyper Cache = Less noticeable improvement than DB Cache, but still noticeable.
  • WP Minify = Essential. Every website should combine, minify then cache static text assets (like CSS and JavaScript) for production.

Note: I have used WP Super Cache in the past and have run into problems. Apparently it doesn’t perform too well on shared hosting setups. Also, in my experience, DB Cache outperforms Super Cache every time.

I have other thoughts about web performance that I’d like to share, but not today. Let me gather my thoughts some more and get back to you.

Know of any other good WordPress performance tricks? Leave a comment.

Posted in
Wordpress
Tools
3 Comments

So long MT, G’Day DH

December 4th, 2009

Well, it wasn’t easy, but I’ve done it: I have migrated my sites away from MediaTemple (MT) to DreamHost (DH).

Why the change? Performance mainly.

MediaTemple has given me decent stability and good support over the last few years. And most of all I’ll miss that gorgeous, minimal admin control panel.

But the performance has been poor at best. Even with WordPress caching plugins installed, page renders averaged 3 seconds, not including the fairly frequent spikes (of up to 30 seconds) which would occur every 5 attempts or so.

And while they seem to have more constant outages (two of which have affected me already), the overall page render performance at DreamHost has been at least twice as good (< 1 second for page render on average) as MediaTemple and far more consistent (i.e: no spikes). For those who are interested, without caching plugins installed, the difference was far more pronounced (averages of 13 seconds for MT and 2 seconds for DH).

The DreamHost control panel isn't quite as minimal or as gorgeous, but it is much better organised than others I tried, and has all the functionality I require.

I should note here that these performance results (especially the DreamHost results) are based on a limited period of testing. So I’ll keep you posted as to the service and performance longer term. But it is safe to say that the performance of my previous provider has been less-than-ideal for a long time, hence the move.

For those interested in WordPress performance, I’ll post a follow up about the plugins I’m using.

Posted in
Web, Wordpress
Tools
No Comments

Slightly nicer URLs

October 17th, 2009

As we know, all unique online resources should be addressable with a unique URL.

However, not all URLs were created equal. Some URLs are “nicer” than others. For example, URLs with query string parameters are often considered to belong to the “not so nice” URL category: http://example.com/?p=1234&vH=10&Session_ID=er5DKJn838JK2dfs

In general, what I consider to be “nice” or “not so nice” URLs is a lengthy topic, and I’ll only touch on part of it today. Suffice to say, that for some purposes, I believe using query string parameters is not the worst crime you can commit. In fact, in some cases, I believe they are perfectly acceptable.

Take the following URL for instance: http://example.com/books/?format=html&order=alphabetical&page=2. Although query string parameters mean this URL is a little tricky to read, at least it uses human-readable parameter keys and values. And because slashes / in URLs imply heirarchy, the only good alternative for this type of URL would be a Matrix URL, like this: http://example.com/books/;format=html;order=alphabetical;page=2.

Implementing Matrix URLs within web applications can be difficult, requiring extra server-side redirects or client-side trickery because by default, a HTML form won’t submit data formatted as a Matrix URL.

That’s why I believe query strings aren’t so bad, sometimes they really come in handy.

Repeated parameters

That said, when using checkboxes (or heaven-forbid) multi-select controls to submit data using the GET method, some server-side languages (like PHP) require that you add [] to the end of the name attribute of each control, for example: <input type="checkbox" name="items[]" value="item1" /><input type="checkbox" name="items[]" value="item2" />

For my money, this results in “not so nice” URLs, for example: http://example.com/books/?items[]=item1&items[]=item2

I know it’s a subtle difference, but I much prefer: http://example.com/books/?items=item1&items=item2

The other benefit is that your HTML wouldn’t need to contain the [] either: <input type="checkbox" name="items" value="item1" /><input type="checkbox" name="items" value="item2" />

A problem

The problem is, by default, if [] doesn’t appear in your URLs, only the last ‘items’ parameter will be accessible to PHP in the $_GET array.

A solution

I spent some time thinking about this, and decided the best thing to do would be to parse the URL myself.

/**
 * Returns query string parameters more intelligently from the URL than by using the $_GET array.
 *
 * When multiple parameters are encountered with the same name, they are stacked into an
 * array. This means all URL data can be accessed without using brackets in name attributes
 * For example, typically you would use: <input name="items[]" /> resulting in &items[]=id1&items[]=id2
 * However, using this method you can use: <input name="items" /> resulting in &items=id1&items=id2
 *
 * @author Andrew Ramsden
 * @see: http://irama.org/news/2009/10/17/slightly-nicer-urls/
 * @license GNU GENERAL PUBLIC LICENSE (GPL) <http://www.gnu.org/licenses/gpl.html>
 *
 * @param String $url (optional) A URL to parse for query string variables. If not set, the
 *        current requested URI will be parsed.
 * @return Array An associative array with all query string variables. Multiple parameters
 *         are stacked into a nested array.
 */
function getURLVariables ($url='') {

	$url = !empty($url) ? parse_url($url) : parse_url($_SERVER['REQUEST_URI']);
	$result = array();
	$queryStrParams = explode('&',$url['query']);

	foreach ($queryStrParams as $param) {
		$paramKeyVals = explode('=',$param, 2);

		if (!isset($paramKeyVals[0])) continue;

		$key = $paramKeyVals[0];
		$val = isset($paramKeyVals[1])?$paramKeyVals[1]:'';

		if (substr($key,-6) == '%5B%5D') { // support ugly urls too
			$result[substr($key,0,-6)][] = $val;
		} else if (!isset($result[$key])) { // add new param to the results array
			$result[$key] = $val;
		} else { // this param already exists, stack into an array
				if (is_array($result[$key])) {
					$result[$key][] = $val; // add to existing array
				} else {
					$result[$key] = array($result[$key], $val); // create new array
				}
		}
	}
	return $result;
}

Now instead of using: $items = $_GET['items']; you can use $items = getURLVariables()['items']; and access all the data from your slightly nicer URLs.

Feedback appreciated, let me know what you think.

Posted in
Identifiers, PHP
Tools
No Comments

Vista, Windows 7, memory use and performance

July 20th, 2009

As hinted previously, I’ve been experimenting with Windows operating systems and hardware for a few years and trying to get the best performance for day to day multitasking and a little gaming.

As promised, this article contains the answers to questions such as:

  • Which Operating System (OS) do I need to use more than 3GB of RAM?
  • 32 bit OS vs 64 bit OS?
  • Which performance tweaks actually work?
  • Which tweaks can reduce performance?

Disclaimer

I’m not a “systems guy”, I’m closer to a systems n00b. If you are a systems person, then I’m sure none of this will be news to you, and you’re probably thinking why is he explaining all this basic stuff? If that’s what you’re thinking, I’ll answer your question with some of my own questions, like where were you when I was looking for simple answers? And where are your articles explaining all this stuff in plain-ish English? And won’t somebody think of the n00bs? (n00bs are people too).
If you consider yourself a systems person and you notice any inaccuracies below, please leave a comment and I’ll update the post, thank you.

Background

  1. There’s no point trying to use more than 4GB of RAM with a 32 bit operating system. Basically, 32 bit Windows systems can only address 4GB, even with PAE (Physical Address Extension) due to driver compatibility issues. And often different internal devices (like your video card) require some of that address space bringing the total addressable RAM that the OS can access down closer to 3GB.
    (sources for this information are inconsistent, but this is the conclusion I reached after much reading, sweating and cursing).
  2. Using a 64 bit OS will allow up to 128GB or RAM available to the OS (as much as you have installed). But a 64 bit OS will cost you RAM also, as all variables are now 64 bits long (instead of 32) this can result in 20-40% more RAM used. So if you are using only 4GB of RAM it’s really not worth switching to a 64 bit OS.
    (see http://www.tomshardware.com/reviews/vista-workshop,1775-5.html)
  3. Some sources will warn against moving to a 64 bit OS because of the unavailability of 64 bit compatible drivers for old hardware. I will say this, 12 months ago 64 bit Vista gave me no end of trouble, but recently, 64 bit Windows 7 has been running very reliably. If you use old hardware or Vista, potential driver issues may be a concern. Otherwise, I think it’s safe to say that 64 bit system users are now first class citizens too and drivers are generally available from all major hardware vendors. It would pay to check first though (especially for any older hardware/peripherals you may be using).
  4. With only 4GB, Vista / Windows 7 fills almost all un-reserved RAM with cached files, but “Physical Memory usage” only reports the amount of RAM actively reserved by applications. This means Windows is putting all the RAM to good use even if it doesn’t appear to be.
    This is visible in Task Manager in the “Physical Memory” area under the “Performance” tab. It displays a high value for “Cached” and low value for “Free” (even though the overall reported “Physical Memory usage” may not be high).
    (see http://www.codinghorror.com/blog/archives/000688.html)
  5. The page file use may seem large (as reported in Task Manager), but it’s not always using that space, that space is only allocated in case active memory needs to be paged. So the page file will always be at least as large as active RAM used, even though data is not being sent to and from the page file.
    This means a high page file value is not necessarily an indication of a performance bottleneck (unless it is much higher than the amount of actively used RAM aka “Physical Memory Usage”).
    (see http://forums.whirlpool.net.au/forum-replies-archive.cfm/929467.html)

Things to do:

  • Lots of RAM is a good thing (4GB is good, 8GB is better)

    RAM is not too expensive these days, so it’s worth shelling out for.
    (see http://www.tomshardware.com/reviews/vista-workshop,1775-12.html)

  • Assign a page file to a different physical hard drive to the system drive

    (see http://www.msfn.org/board/lofiversion/index.php/t12014.html and http://www.tweakxp.com/article37023.aspx)
    Notes:

    • You can use more than one disk for added performance.
    • Don’t use a second drive alone if it is slower than the system drive.
    • Don’t move the page file to a partition of the system drive (very bad for performance).
    • Don’t assign your page file to a RAMDisk as this just reduces the available RAM and creates references back to RAM anyway. Instead, just add more RAM to reduce the necessity to page.

  • Set a static size for the page file (but give it room to grow)

    Whenever Windows dynamically adjusts the size of the page file, the application that requires the extra swap space has to wait. Set a static file size for the page file (initial size = 1.5 times your amount of RAM and maximum size = 2 or 2.5 times your amount of RAM). This way, most of the time the page file will not need to be resized, but can if necessary. Allowing it to resize for situations of abnormally large memory usage may avoid crashing applications (and losing unsaved work).
    (see http://www.extremetech.com/article2/0,2845,2156185,00.asp)

  • Defragment drives that contain page files

    After performing step 3, it’s worth defragmenting the drives being used with system tools, then run PageDefrag because normal defragmentation can’t operate on active page files.
    (see http://technet.microsoft.com/en-au/sysinternals/bb897426.aspx)

  • Trust Vista / Windows 7 to do the job properly

    Task Manager may report only 40% – 60% RAM used yet report a large page file, which can seem counter-intuitive at first. It’s easy to assume that Windows is not managing memory well, that it’s paging memory too soon and must be needlessly thrashing disk I/O when you switch between applications.
    This is not the case, the rest of your RAM is being used for file caching and the large page file usually only represents reserved space (see points 4. and 5. in the Background section).
    (see http://www.codinghorror.com/blog/archives/000688.html)

With 8GB, also do this:

  • Try increasing the FileSystem Memory cache

    This is only worth trying if the “Free” Physical Memory reported in the Task Manager is quite high. Vista / Windows 7 will usually use a lot of memory for caching by default without this tweak (see point 4. in the Background section).
    (see http://www.howtogeek.com/howto/windows-vista/increase-the-filesystem-memory-cache-size-in-vista/)

    • Open up an Administrator mode command prompt by right-clicking and choosing Run as Administrator, or type in cmd into the start menu search box and use Ctrl+Shift+Enter.
    • Enter fsutil behavior set memoryusage 2
    • Restart Windows. (to revert use fsutil behavior set memoryusage 1)

  • Reduce or disable the page file?

    While this is only really feasible for a Vista / Windows 7 system with 8GB or more of RAM and may result in a small performance improvement for switching between memory intensive applications, it will likely cause an application to crash in the event the RAM is ever filled. Remember, it’s always best to have at least 1.5 times your total RAM available for paging and then just let Vista / Windows 7 get the job done.
    (see http://www.tomshardware.com/reviews/vista-workshop,1775-6.html)

Things not to do:

  • Don’t reduce the page file or disable it entirely.
  • Don’t assign your page file to a slow drive or a separate partition of the system drive.
  • Don’t assign your page file to a RAMDisk (this just reduces the available system RAM).
  • Don’t increase the FileSystem Memory cache if your applications max out your RAM frequently.

The wrap up

I hope you found something amongst these tips useful, and I hope it saved you some time.

PS If you are interested in gaming performance, it depends on the game, but to cover all your bases I can recommend all of the above plus Windows 7 (or XP), a quad-core CPU, a fast hard drive (consider a SSD) and a beefy video card ;)

Posted in
Windows
Tools
1 Comment
« Older Entries