WP feeds performance? Miserable!

Published: On Friday, June 22, 2007

Today I get an interesting idea: to explore WordPress’ **power demands while feeds content generation**. That means I probed how much time it takes to generate a XML file (either RSS or Atom, either with posts or with comments). I *hoped* that WP developers *presumed* – that feed pages are going to be the most hit pages, pages creating most of the traffic (sure, not measured in data volume in bytes but for example in DB queries). Obviously, they didn’t do so.

Now, of course I could make a nice table showing “exact” numbers, times and query-counts, but there’s no need. It’s enough to say: “To create a feed takes the same time as to create your WP index page.” Sometimes or somewhere it can be 0.15 sec., sometimes maybe 0.25 sec. This is not important because we know, it’s too much.

I am a man who thinks about power requirements of the software he makes, quite much. Before I write a piece of code, especially if the code works with database data, I think about the requirements. First I try to estimate total number of queries for a page and then I try (at least for a really little while) to find a better solution. What if some of these queries are in fact unnecessary? What if my script takes twice more time than it could… if I would present to the problem *one tiny moment of my brain activity*? This is the way I develop software, thinking forward. I presumed WP developers do the same thing, they should, but they do not.

Well, the problem is clear, I think. Who needs an illustration, example…? Ok, look. My blog visits about 150 people per day (-> it’s a little project). In the last month (May 2007), my blog’s home page was displayed about 2700 times. Let’s say 3000, to make it easier. But. The feed (RSS feed with posts) was shown over 30 000 times. Now you understand surely: **the feed should be generated faster than everything else**. It’s almost comic to think about your common pages’ performance while your feeds are the cause, the real source of most of the DB traffic (or CPU time…).

Try it yourself…

Just open *wp-includes/feed-rss2.php* and at the last line add this code:

/—code php


Then open your “feed .(RSS, articles)” in the browser, show source and look at the end. There is it.


We (You) have two options how to solve this problem (yes, I think it’s a serious problem).

Either **cache**… yes, caching the content of feed for an (un)defined time, so that is no more necessary to call all 15 (or how many) queries everytime you reload feed. By the way – I didn’t read the code precisely, but why 15 queries? Isn’t this wasting? Go on… eh, actually cache, or some partial saving of powers is not the solution I would prefer. Because it’s partial. And at this case, it’s pointless to do things partially. Not perfect.

Or **feeds’ statification**. That’s my term :). I think it is the best option I could create at this moment – to make **feeds static xml files**. They would be re-generated after every change, that could influence feeds’ content. You know: if you publish an article, if you make a change in some, if you change a setting or permalinks structure, if you just click yet non-existing button “Regenerate feeds” for example, if you activate a plugin… and so on. On events like these a script would be called, that would regenerate feeds’ content (btw, who today uses Atom format?), the content would be saved into the feed.xml file, **so until next regeneration no DB query would be necessary** because of feed reading.

So think about that, dear WordPress developers. 30 000 times a month my blog’s WP installation has to reload the feed-page. More than 450 000 DB queries are made in one month. This is a horrible number, if you know, that 449 000 queries are… pointless.


Comments are closed.

I quit working with WordPress, comments are closed. My plugins will not be updated any more – at least not by me. Feel free to modify my source codes though… Also I am not able to provide support, sorry. –Kahi