Wordpress is a Memory Hog
Did you know Wordpress is one major memory hog? No? Neither did I until I started getting “500 Internal Server” errors after having my hosting account at Joyent moved from FreeBSD to OpenSolaris, with it’s resource management functionality being used to it’s full extent.
You’ll be surprised to hear this appears to be a topic that isn’t really discussed much out in the open. The closest indication of anyone else encountering memory issues with Wordpress is this this post on the Wordpress support forum.
This is a great post and provides a good example that illustrates how much memory Wordpress really uses, and an good explanation as to why. In short, it seems Wordpress loads pretty much the entire options table into $GLOBALS when it initialises. This causes the memory usage to jump significantly.
I tested the suggestions in the forum post on a relatively clean installation and sure enough, the memory usage goes from a mere 50 Kb before Wordpress initialises to a massive 5.79 Mb after Wordpress has initialised, and then finally a maximum of 5.81 Mb once it’s all done.
What a jump. OVER 5 Mb of memory attributed to Wordpress alone, and most of this is consumed by the vast amount of crap loaded into $GLOBALS.
Things are further compunded by plugin writers not knowing about the autoload functionality, which defaults to “yes”, when adding their plugin options to the options table, and then not removing their options when the plugin is disabled.
The lack of knowledge of the autoload functionality and it’s consequences can probably be put down to some bad documentation and Wordpress has always had an issue with options left over by plugins that are no longer installed, but does Wordpress really need all that information loaded into $GLOBALS on initalisation?
I don’t know, but I plan to find out.
Search
Recommended Book
Related Entries
- Experimenting with Wordpress Option Autoloading
- Update on Wordpress Autoload Option Experimentation
- Now Running Wordpress 2.5 RC2
- Wordpress 2.5 Now Available
- Habari: First Impressions
- Debugging Wordpress
- PHP FastCGI, Lighttpd and Memory Leaks
- Pedantic Wordpress
- Time to Live By The Seat of My Pants
- HOWTO: Change Wordpress Table Prefix
Hi,
I’ve hacked around wordpress quite a lot to suit for my website. and i’ve noticed that WordPress cares the least about memory management.
these difficulties i guess are caused due to:
1. unclassed global functions that get loaded every time someone makes a request
2. poor usage of serialization of objects (actually there are few objects)
I can tell this as i’ve also seen MediaWiki’s code they have about 30mb of it and still you can hardly notice any memory usage! performance is their main preference.
so i’ve set out to hack it to use less memory… here’s the wiki page http://codex.wordpress.org/Memory_Tweaks
if anyone can help please join me.
Good luck. I’ve had a look through the code too and I think you may be in for one big challenge and a fair amount of re-architecture of the way the underlying Wordpress code works.
While doing some work on my plugin that aims to provide an easy and safe way of cleaning out the options table, I noticed the schema has changed. The autoload field used to be ENUM yes/no, but now it’s VARCHAR(20).
The only thing I could find out about it was a trac which had “we’re stuck with it”. It seems to me VARCHAR(20) is not optimal for only “yes” or “no”, so maybe something is in the works? One can only hope so. A few of my plugin users have experienced problems with memory limitations (they had thousands of rows!), so I have optimized the plugin’s database queries, but some WordPress performance improvements would be most welcome.