skip to main content.

while updating some old posts with photos (just designwise, no content changed), i once again experienced a complete lockdown: the server became incredible slow and was floaded with apache processes, and i had to shut down and kill -9 all apache processes several times to be able to continue to do anything except waiting. this isn’t the first time this happend, but this time i had apache’s logging enabled (waiting for something like this) to see what was causing all the accesses. well, out of the 13.000 logfile entries (ranging over a week, i think), around 3.300 were by wordpress – and 99.9% of these happend in the last few hours, while i was updating the old posts. it seems that every time i updated a post, wordpress accesses all links and images in the post, also the local ones, and downloads them. yes, downloads them – also the big versions of panoramas. and if i’m updating posts with often 10–30 photos, some of them large, this clearly explains why the web server was dying. to put it that way, wordpress dosed itself. (the funny thing is that it did not first use a head first, to see what kind of link this is, but starts with a get to first download the whole thing. after downloading all links and images, it uses head on them.)
anyway. i don’t know at the moment what to do against that.
but another annoying thing is that the blog is loading rather slow. i also decided to see what is causing this. well, it turns out that the old main page was doing 298 sql queries. after disabling role scoper, this jumped down to 34, with loading times more or less the same. but then, i disabled the tag cloud. this just saved one query, but reduced the page generation time from around 10 to 2 seconds. wow. enabling role scoper again (i really need that one), i now have a bit less than 50 queries with maybe 4-5 seconds of page creation time.
well, still far from optimal, but already faster.

posted in: daily life thoughts www


felix wrote on march 1, 2009 at 06:46:

i just installed a php cache, which seems to speed up the site again. moreover, i modified some apache settings. i hope the performance is way better now.

Kevin wrote on march 1, 2009 at 18:41:

The db query results stated here regarding Role Scoper are not normal. Role Scoper will normally add 10-12 queries to the front end if you have its cache enabled (which is the default setting), and maybe 20-25 if it’s disabled. I have put extensive design and testing efforts into keeping its server toll as low as possible while adding a lot of flexibility to WP permissions.

What version of RS were you running? Tomorrow I’ll take some time to redo the performance tests and follow up with you re: your configuration.

Kevin wrote on march 1, 2009 at 18:52:

I just want to emphasize my request to please contact me regarding your horrendous server performance so I can diagnose how Role Scoper could have caused it. If you examine my support forum I think you’ll see that I’m dedicated to correcting any bizarre symptoms promptly – not just explaining them away.

The plugin is an ambitious project which I have put months of unpaid work into. Though very near release, it is still in the beta phase. When someone’s implementation of it reveals an unforeseen glitch, the success of the project is very dependent on their willingness to provide me with some informative feedback.

felix wrote on march 1, 2009 at 19:13:

hey kevin, thanks for your reply! i’m using version 1.0.0-rc9.9213 of role scoper, with default settings.
the current amount of queries sounds ok (42, compared to ~35 without rs); i guess the main problem with the insane amount of queries (298) was due to combination of role scoper with the tag cloud (generated by simple tags 1.6.4) (it was configured to display 135 tags); it seems that simple tags itself needs one query to fetch the tag cloud, but i assume that role scoper had to check every result line of that query for visibility; if that requires ~2 queries per tag, that would explain the additional ~260 queries.
i just enabled the tag cloud again, and it increased the 42 queries to 302. so i assume that’s the reason. (it still needed just one second more to render the page, though – maybe due to the role scoper cache, the mysql query cache, and/or the php cache.)
anyway. thanks really a lot for that plugin!

Kevin wrote on march 2, 2009 at 22:13:

This is fixed in the new Role Scoper development snapshot (rc9.9229).

My tags filter was including t.* but not tt.*. Simple Tags, unable to find a “taxonomy” property on the tag object, forced a requery of each tag (which also forced a second query for obscure reasons I won’t elaborate on).

Thank you for reporting this. The bug and fix potentially apply to other plugins or themes that work with tags.

Kevin wrote on march 3, 2009 at 18:32:

…one last update: I further updated the Role Scoper development snapshot (to rc9.9302) due to a new bug in rc9.9229