Wordpress 2.8 Memory Usage and Bloat, Phillip Colla Photography

I’ve been a fan of Wordpress for almost six years. I started blogging with Wordpress in 2005 and have upgraded several times over the years as new versions have come out. However, it may be time for me to say TTFN to Wordpress. I am usually very slow to upgrade any software I use, preferring to let others discover bugs first and waiting for a few maintenance releases before upgrading. However, after reading that Wordpress 2.8.3 contains several security fixes, on Friday I made the jump from 2.7 to 2.8.3. As soon as I did so problems arose, bringing my server to its knees and causing a variety of crashes. After two days studying the situation, reading up on recent Wordpress forums, making some configuration changes on the server on which my website is hosted and adding some diagnostic code to the Wordpress source itself, I am finally in a position to say with some confidence: Wordpress 2.8.3 is seriously bloated.

Triple the Memory == Bloat

It appears to me that recent programming changes in Wordpress have caused it to use quite a bit more memory than it did before. It could be that one change is responsible for much of the bloat, or that many small changes are each responsible for their own small shares of the problem.

Let me give an example to illustrate how significant the issue is. When a browser requests my most recent blog entry about humpback whale pictures, a PHP memory allocation on my web server of only 2.8 MB is required when using Wordpress 2.7. However, if Wordpress 2.8.3 is installed the required allocation balloons to 10.1 MB. That’s a factor of 3.6, or 260% more memory. (See below under “Instrumenting …” for how you can determine the memory allocation of your own Wordpress installation, its quite simple.) Visitors to my site don’t see ANY difference with the blog content yet by virtue of upgrading to 2.8.3 the web server was forced to allocate more than triple the memory. That’s crazy.

To see how widespread this problem is, Google “Wordpress + 2.8 + Fatal + Error” or keywords like that. You’ll find that many people have reported problems with memory allocation failures occurring on their web servers after upgrading to Wordpress 2.8. Now, here’s the curious part. The common wisdom in these online discussions seems to be to allow PHP (the scripting language upon which Wordpress is built) to use more memory. For instance, a typical installation of PHP and Wordpress might allow each instance of Wordpress serving up a page to use, say, no more the 32 MB of memory. The Wordpress community seems to recommend raising this limit to 64 MB to make the memory allocation failure problems of Wordpress 2.8.3 go away. Raising this limit can be done in a few ways: 1) by modifying wp-settings.php so that WP_MEMORY_LIMIT is initialized to 64M rather than 32M, and/or 2) by setting “php_value memory_limit 64M” in your .htaccess file.

As I searched the net on this issue I saw some comments essentially saying “This is just a server configuration issue, increase the memory to 64M”. Hello? Just a server issue? No, this is in fact a coding issue. If one requires 64 MB to display a page of text with a few widgets around it, something is wrong.

Simply put, increasing PHP’s memory limit is a short-term fix and is sidestepping the true problem, which is code bloat and inefficient programming. Allocating 64 MB to serve up a blog page is overkill, in fact 32 MB is more than enough. Realistically, a lean and mean blog should only require a few MB to do its thing. Think about it, how much memory does it take to query an entry from a MySQL database, run some ancillary functions to surround it with headers, widgets, titles, blogrolls, etc., format it and then present it to the output stream? If your Wordpress pages require more than 32 MB to serve, you had better have very few visitors, a powerful server or an expectation that you will periodically crash on your visitors. If you allow PHP to use up to 64 MB to serve up a single blog page, and you suddenly have a rush of visitors (say 10 at a time), you need plenty of memory on your server, or at least plenty of burst memory, or you stand a chance of have a failure of some kind that one or more of your visitors will see.

My hunch is that prior to Wordpress 2.8, few Wordpress users had to fiddle with the memory limit.

Traffic

My weblogs say I get about 5000-6000 unique visitors to my site each day, in addition to search engine crawlers. (There are fewer in the summer when students aren’t raiding photos for their reports). There are times when 100+ simultaneous instances of the httpd daemon are running on my server. Each page view (not just each visitor) invokes a new instance of the Wordpress software which, using 2.8.3 on my installation, would need 10 MB just to serve up the page. My server currently has about 400MB of real memory available, and up to 1 GB in “burst situations” (its a virtual private server). Using Wordpress 2.7 I rarely observed occasions when too many simultaneous page views caused an out-of-memory situation. In fact I figure it would take roughly 125 simultaneous views to use up the real memory and 300 or so to exhaust the burst memory. However, immediately after I installed Wordpress 2.8.3 on Friday I began to see PHP fatal errors and server daemons (services) dying due to lack of memory. They continued to occur at least every hour, at times when lots of people hit the site simultaneously. At 10 MB per page view using Wordpress 2.8.3, it would only take 40 simultaneous views (including search engines which are constantly pounding my site) to eat up the physical ram and start causing problems for the server.

After installing 2.8.3 and encountering problems, I first tried raising the WP_MEMORY_LIMIT and PHP memory limits to 64M as recommended by other Wordpress users, but the problem continued. I’ve made lots of custom tweaks to my installation of Wordpress, and am not afraid to fiddle with the code to get things to work better. So I set out to make some changes to the code in an effort to figure out what was going wrong.

Instrumenting Wordpress

To learn how much memory was being used by PHP to serve up a blog page, I added a few well placed calls to the PHP functions memory_get_usage() and memory_get_peak_usage(). memory_get_usage() reveals how much memory is in use at the moment the function is called, while memory_get_peak_usage() shows the maximum amount of memory required up to the point the function is called. In the index.php source file in the main Wordpress directory, I added the line

echo memory_get_peak_usage();

just before the final “?>”. This produced an additional line at the bottom of the blog, showing the peak memory use (in bytes) required by PHP to run the Wordpress scripts that generated the page being viewed.

(Note: calling this simple line of code instrumentation may be a bit rich since it is nothing more than one line of debug code. I actually instrumented wp-settings.php, adding memory checks before most of the require and require_once statements. Doing this allowed me to watch the memory accumulation ratchet up as each require statement is executed. I did not see a single obvious point where the memory ballooned, rather the accumulation was steady across all the require statements.)

It was in this way that I learned that Wordpress 2.8.3 was using over 10 MB to serve up a single blog entry in my installation. This was the default installation of 2.8.3; the only change I made was to the theme (I use classic) and one plug-in. I tried uninstalling the only plug-in (WP-Geo) but it made virtually no difference. It appears the bloat is in the Wordpress code itself. I made the same one-line addition to index.php in my 2.7 Wordpress installation and was pleasantly surprised to see how little memory was required, only 2.8 MB. The solution was obvious: revert to my prior Wordpress version. Since I had kept a copy of the entire Wordpress directory structure on my server before upgrading to 2.8.3, reverting to 2.7 was just a matter of renaming directories and running a few tests.

Conclusions

I wrote the code for the non-blog part of my stock photography web site to use between 1 and 3 MB of memory for any given page. For instance, this page of bald eagle photos requires about 2.5 MB of PHP memory to load. I’m comfortable with that. But 10 MB, which is what Wordpress 2.8.3 was requiring for a simple blog page, is simply too much. So I have reverted back to Wordpress 2.7 for now, and am keeping my fingers crossed that the talented Wordpress development community can make some improvements in the memory usage. My sense is that the community development for Wordpress focuses on adding “features” and little energy is devoted to improving existing code so that it operates more efficiently. However, if enough users experience the bloat problems that I have seen, Wordpress developers may take the issue seriously. We’ll see what happens. I am hopeful.

I’m also doubling the amount of memory on my server. Just to be safe.

A few related links:

Blue Anvil Journal » Blog Archive » Wordpress 2.8 Memory Usage
Seven Reasons Why Wordpress 2.8 Is Better Than Ever | Clint Maher
Allyn Gibson · On WordPress Woes
Google Search on “Wordpress” + “2.8″ + “64M” finds hundreds of comments on this problem.

Keywords: Wordpress, memory usage, upgrade, bloat, blog, software, version, server, PHP, fatal error, allocation failure.

Subscribe to this feed - Subscribe via Feedburner - Stumble it! - Digg this! - Add to Del.icio.us - Share on Facebook