I’m a sensitive soul with computers. Whilst I appreciate the incredible power and capacity that modern computers provide, I cannot help but remember those hazy days during my youth when I learned how to program. My first computer was modest by today’s standards – a
So how does WordPress fill this tiny pocket of the big machine? Today I’m looking at the memory footprint of WordPress 2.0.2. How efficiently does WordPress use its most precious resource?
PHP provides limited memory diagnostic tools as standard. One. memory_get_usage() returns the amount of memory, in bytes, currently allocated to the running PHP script.
Plan
PHP alone
Default installation (no plugins, default theme, default data);
Default installation (no plugins, default theme), with posts and comments;
Memory Probing Plugin For WordPress
WordPress Component RAM Usage
Core
Caches
Admin Interface
Plugins
Same Tests On Latest SVN WordPress
Same Tests With PHP4
Libertus says:
Baseline PHP Script Memory Usage
The tests are all run on my localhost environment, an AMD K7 running Ubuntu Linux (Dapper Drake).
Copyright (c) 1997-2006 The PHP Group
Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies
34816
I’ll take that as 40 kilobytes.
May 29, 2006, 8:42 amLibertus says:
Baseline WordPress 2.0.2 Memory Usage
A standard installation of WordPress 2.0.2 on a new MySQL database. The main thing I want to avoid doing is running the Dashboard, which I know to have an effect, albeit minor, on the overall WordPress memory usage. I rename wp-admin/index.php to .index.php.
Before first run I must patch the source at the correct places to give a baseline memory reading. Here I have a cunning plan. WordPress is a very customisable program due to its plugin architecture. At many points throughout the WordPress program, third-party modules can be hooked in to do just about anything. I’m going to patch the plugin points to give a readout of the memory usage throughout an entire run of the WordPress program.
To the top of function do_action() in wp-includes/functions.php I add a single line:
Yes, this will increase the memory usage but I am guaranteed to get the baseline in the first few elements of the array. The size of this graph array is deterministic and can be easily and progressively eliminated from the reported memory usage.
All this information has to go somewhere to be analysed or it ain’t much use. I’m expecting quite a lot of data and many sets of it, so I reckon I’ll serialize, gzip and dump into a timestamped file. This has to be done right at the end of the program, which is an opportunity to get the final memory size statistic. I add the following lines to the end of index.php:
Are we sitting comfortably? Let’s begin.
First Run
The administrative interface seems to work and allows me to update the admin profile. Does the front-stage work? Yes! The default WordPress installation seems to run. Now, do I have any memory probe files to play with? No. None. Damn!
I check the Apache error logs to see if there’s any particular reason. Nothing. Maybe the code I added to index.php isn’t being executed.
Checking around I find wp-includes/template_loader.php which is festooned with exit statements. My memory probe dump code isn’t being called. I’ll have to use another way: register_shutdown_function(). I amend index.php to have the following code at the top.
Second Run
First Memory Dump
<?php
$memory_graph = unserialize(gzuncompress(file_get_contents($_SERVER['argv'][1])));
foreach( $memory_graph as $index => $reading ) {
list( $tag, $memory ) = each($reading);
echo "$index,$tag,$memory\n";
}
?>
1,init,3347112
2,pre_get_posts,3327184
3,template_redirect,3364960
4,wp_head,3384816
5,loop_start,3378560
6,loop_end,3383216
7,wp_meta,3411248
8,wp_footer,3404016
9,0,end
Baseline WordPress memory usage appears to be 3.2 megabytes, comfortably under a half of the available memory limit.
A couple of minor bug-fixes to my probes and I'm ready to start my analysis.
Baseline WordPress Memory Usage
0,plugins_loaded,3276736
May 29, 2006, 9:59 am1,init,3347016
2,pre_get_posts,3327088
3,template_redirect,3364864
4,wp_head,3384720
5,loop_start,3378464
6,loop_end,3383120
7,wp_meta,3411152
8,wp_footer,3403920
9,end,3397160
Libertus says:
Analysis Of Baseline WordPress Memory Usage
WordPress needs 3MB of RAM to load and an extra 150KB to process the default content with the default theme. That’s not at all bad, for a start. Now I’ll start making the blog more realistic by adding features and content.
Enable The Dashboard, Look At It, Look At Blog
How much RAM does the Dashboard take if you don’t look at it? I suspect the answer is around 200KB. I rename back wp-admin/index.php, browse the Dashboard (April Fools!) then view the blog.
1,init,3346536
2,pre_get_posts,3326608
3,template_redirect,3364384
4,wp_head,3384240
5,loop_start,3377984
6,loop_end,3382640
7,wp_meta,3410672
8,wp_footer,3403440
9,end,3396680
No, I’m wrong. The Dashboard seems to have no effect on overall memory use. Great stuff!
The Effect Of Content
So far I’m only looking at the blog homepage. It has one post with one comment. I add another post, something big enough to show up on the graph. I’ll add a picture too using the inline uploading. With all the previewing and stuff, I should get quite a few probes during the process.
Three probes to be exact. I’m not sure which one relates to which activity, so I’ll have to examine them all.
1,init,3343544
2,parse_query,3304032
3,pre_get_posts,3304480
4,template_redirect,3351696
5,end,3372168
1,init,3343544
2,parse_query,3304032
3,pre_get_posts,3304480
4,template_redirect,3350936
5,end,3371760
1,init,3346568
2,pre_get_posts,3326640
3,template_redirect,3367688
4,wp_head,3388000
5,loop_start,3381880
6,loop_end,3389064
7,wp_meta,3414864
8,wp_footer,3407632
9,end,3400872
My post appears to consume very little memory, no more than I would expect. Text doesn’t take up much space. Expand the dataset a little. Import a few hundred posts and comments. My database now comprises 64 posts and 63 categories with a total data size just over 100KB. How much memory does the homepage now use?
Mmm… Baklava Tart
Nothing like looking at a recipe blog to make you hungry! My drooling aside, how much trouble did these numerous new posts give WordPress?
1,init,3348088
2,pre_get_posts,3328232
3,template_redirect,3441088
4,wp_head,3454952
5,loop_start,3447936
6,loop_end,3460944
7,wp_meta,3497376
8,wp_footer,3488544
9,end,3481720
The trouble with looking for small things in large numbers is that the scale often confuses. The WordPress homepage deals with two things; 10 posts and the sidebar. Subtracting the latest ‘wp_meta’ (the peak memory) reading from the previous gives 82512. For now it’s just a number. Hopefully soon it will be a formula.
Preliminary Conclusions
So far nothing at all to worry about. WordPress seems like a model citizen, leaving more RAM available than it consumes and consuming RAM proportionate to its task. Not good enough! It must break!
May 29, 2006, 11:11 amLibertus says:
WordPress Memory Usage Across Tasks
The homepage alone is insufficient. I need to probe memory use across some other common tasks such as showing a single page, categories and the like. My basic assumption is that the more a page shows the more RAM is required to process it. That makes the single page view the most likely culprit for breaking memory limits, especially if there are many comments against a post.
First, my probe code must be updated to record the requested page.
Single Post, No Comments
1,init,3347416
2,parse_query,3327648
3,pre_get_posts,3327968
4,template_redirect,3368400
5,wp_head,3393016
6,loop_start,3386760
7,comment_form,3428056
8,loop_end,3415032
9,wp_footer,3418176
10,/~paul/wp-memtest/?p=36,3407384
Sweet. As I would expect, a lower memory use than the homepage.
Time to import a monster post with many comments. “Liberating Wordpress” will do the trick.
Monster Post, Many Comments
Liberating WordPress sure is a monster post. Does the memory probe reveal how monster?
2,parse_query,3326800
3,pre_get_posts,3327120
4,template_redirect,3367032
5,wp_head,3391552
6,loop_start,3385296
7,comment_form,3686704
8,loop_end,3669784
9,wp_footer,3672224
10,/~paul/wp-memtest/?p=210,3660856
Oh come on! Those numbers are totally useless! I can’t quickly subtract 3 million and something from 3 million and something else. I’m more interested in the delta, the change from one reading to the next. Easy.
1,init,3346568,69952
2,parse_query,3326800,-19768
3,pre_get_posts,3327120,320
4,template_redirect,3367032,39912
5,wp_head,3391552,24520
6,loop_start,3385296,-6256
7,comment_form,3686704,301408
8,loop_end,3669784,-16920
9,wp_footer,3672224,2440
10,/~paul/wp-memtest/?p=210,3660856,-11368
There… much better. I can see that my post is indeed a monster, consuming 300KB during the loop. Still, that’s not bad. Time to take a tour. Take some feeds, perhaps?
Preliminary Front-stage Analysis Complete
I cannot find fault with the use of memory by WordPress when performing its core functions. After a short browse of the test blog, including a few searches, my final memory analysis for the homepage is as follows:
1,init,3346704,70040
2,pre_get_posts,3326776,-19928
3,template_redirect,3412152,85376
4,wp_head,3431728,19576
5,loop_start,3425416,-6312
6,loop_end,3445016,19600
7,wp_meta,3483704,38688
8,wp_footer,3474872,-8832
9,/~paul/wp-memtest/,3468048,-6824
Next, the admin interface.
May 29, 2006, 12:35 pmLibertus says:
WordPress Administrative Interface Memory Usage
My probes are being gathered during the admin interface but not dumped. I reckon wp-admin/admin.php is a good place to register my shutdown function which dumps the memory probe data.
First Run
I do like it when things work first time. Especially this time, as the results confirm something I already knew.
1,init,3413632,70152
2,admin_menu,4031776,618144
3,admin_head,4000568,-31208
4,admin_notices,4022600,22032
5,update_option_rss_42109a30548dd2078da9009859b481aa_ts,4346512,323912
6,activity_box_end,4374360,27848
7,update_option_rss_0ff4b43bd116a9d8720d689c80e7dfd4_ts,4464528,90168
8,update_option_rss_867bd5c64f85878d03a060509cd2f92c,4964856,500328
9,update_option_rss_867bd5c64f85878d03a060509cd2f92c_ts,4647880,-316976
10,admin_footer,4543160,-104720
11,shutdown,4483112,-60048
12,/~paul/wp-memtest/wp-admin/,4478824,-4288
The Dashboard is a monster! It uses 4964856-3343480=1.6MB of RAM, a fifth of the total! I hope this is a limited phenomenon.
Write A Post, Post A Picture
Hmm… I appear to have introduced a bug. On uploading the picture for my post, the picture upload box says It worked before. Maybe a different picture. Odd, the second picture worked fine. I’ll try the first one again.
Why does my image named upload OK but my image named does not? It might be the spaces in the filename, so I’ll replace them with dashes. Upload . No, same response.
Is something wrong with the image? Oh. Yes. Duh! is 12.7MB in size! Not a hope in hell of uploading that. I’ll need to drop it in size, to under 2MB, which is the standard upload file size limit. A quick “file save as…” later and I now have a rather more svelte 750KB JPEG. Upload that. It works, almost. Although I can clearly see a thumbnail of the picture, the options menu tells me there is no thumbnail associated with the image. Whatever.
After a bit of faffing, I post some pictures and a bit of text. What memory probe goodness have I got?
WordPress Write Post and Inline Image Uploading Memory Use
I have 15 probe files so I must have been doing more faffing than I thought. There are a lot from the inline uploading, as I expected. I get the feeling that I’m losing probe data due to the admin interface program being executed more than once per second. The reading I was after, the actual saving of a post, is as follows:
1,init,3472960,73672
2,admin_menu,4090776,617816
3,check_admin_referer,4043952,-46824
4,publish_post,4065600,21648
5,save_post,4241208,175608
6,wp_insert_post,4241208,0
7,edit_post,4270256,29048
8,publish_post,4270256,0
9,save_post,4271456,1200
10,wp_insert_post,4271456,0
11,shutdown,4262984,-8472
12,/~paul/wp-memtest/wp-admin/post.php,4262224,-760
Nothing unusual.
Minor Changes To The Probe
I ensure that the dump output filename is unique.
Clean Sheet, Once More With A Post And Pictures
No need to bore with the details. Overall, WordPress uses memory efficiently, apart from the Dashboard.
May 29, 2006, 1:21 pmLibertus says:
Nothing Unusual?
Wait a minute! Between initialisation and admin_menu hooks being called, 600KB of RAM is consumed. I didn’t pay much attention to that earlier on because it was just there. Now I think I’ll take a closer look. If that figure could be reduced, the WP admin working set might drop below the magic 4MB limit.
What consumes 600KB between init and menu?
Tracing The Path Between Initialisation And The Admin Menu
Action ‘init’ is triggered at the end of
wp-settings.php, which is required bywp-config.php, which is required at the beginning ofwp-admin/admin.php.Action ‘admin_menu’ is triggered at the end of
wp-admin/menu.php.The code that needs to be examined lies between lines 19 to 54 of
wp-admin/admin.php. The quickest way to find out what’s happening is to add more of my little memory probes. Here’s a Dashboard memory dump to get your teeth into.1,init,3417504,70048
2,post-admin-functions,3850776,433272
3,post-admin-db,3949256,98480
4,post-registration-functions,3978648,29392
5,post-auth_redirect,3978880,232
6,post-nocache_headers,3979000,120
7,post-update_category_cache,3979000,0
8,post-get_currentuserinfo,3979168,168
9,pre-menu,3980288,1120
10,admin_menu,4037104,56816
11,admin_head,4003152,-33952
12,admin_notices,4025184,22032
13,update_option_rss_42109a30548dd2078da9009859b481aa_ts,4348832,323648
14,activity_box_end,4376616,27784
15,update_option_rss_0ff4b43bd116a9d8720d689c80e7dfd4_ts,4466824,90208
16,update_option_rss_867bd5c64f85878d03a060509cd2f92c,4967152,500328
17,update_option_rss_867bd5c64f85878d03a060509cd2f92c_ts,4650208,-316944
18,admin_footer,4545680,-104528
19,shutdown,4485632,-60048
20,/~paul/wp-memtest/wp-admin/,4481344,-4288
The inclusion of
wp-admin/admin-functions.phpconsumes the most RAM followed by the database “abstraction” layer inwp-admin/wp-db.php. Given the nature of these files, I am not at all surprised by the scale of the memory usage so I can’t imagine I’ll find much to trim away. Best to be sure though.Why Do The Admin Functions Need 400KB Of RAM?
No reason I can see. It’s just a big file that costs 400KB to load.
Why Do The Database Functions Need 100KB Of RAM?
This file constructs an object that connects to a database. If that only costs 100KB of RAM, fantastic!
May 29, 2006, 2:59 pmLibertus says:
Memory Usage of Plugins
Your requests in a comment below please.
May 29, 2006, 3:35 pm