Flutterby™! : MediaWiki help

Next unread comment / Catchup all unread comments User Account Info | Logout | XML/Pilot/etc versions | Long version (with comments) | Weblog archives | Site Map | | Browse Topics

MediaWiki help

2007-05-24 22:28:44.430284+00 by Dan Lyke 9 comments

Before the server switch, I installed MediaWiki on LigHTTPD talking to PostgreSQL over at Flutterby.net, and while performance wasn't screaming, the site was usable.

The new server should be several times faster than the old server, but running under Apache, it's now a dog. If I run top while the requests come in I see the hit on PostgreSQL, and then over the next few refreshes Apache pops up in CPU a couple of times, but the CPU utilization is low, PostgreSQL isn't complaining, so it seems like something in the Apache/PHP is stalling on I/O in some bizarre and performance sucking way.

Anyone got a suggestion of where to start?

comments in ascending chronological order (reverse):

#Comment Re: made: 2007-05-25 03:00:47.564953+00 by: meuon

MediaWiki, dispite "Wiki" meaning Quick in Hawaiian, is a big slow pig designed to run with lots of hardware and tuned server configs. Google: "MediaWiki is Slow" It makes my code look svelte.

#Comment Re: made: 2007-05-25 06:33:25.318501+00 by: dexev

I would start with setting up postgres to log all queries (and execution times) to rule that out -- if you're doing a table scan or similar on every request, that might not show up on CPU.

How's your network latency going to the new server?

#Comment Re: made: 2007-05-25 13:17:19.011622+00 by: other_todd

Most of the MediaWiki wranglers I know seem to think that the first step is caching PHP.

http://eaccelerator.net/ has been mentioned enough times that I took notice of it specifically, although I have not yet tried the product as I am a Perl Guy(tm) and would prefer not to be using PHP at all. When we install MediaWiki here it will be our one and only PHP app, which is one more than I ever wanted to maintain.

#Comment Re: made: 2007-05-25 13:42:04.107933+00 by: Dan Lyke

I may try Twiki again before I start trying to performance tune this setup, just in case it doesn't hit all those same wacky buttons.

I'd chalk it up to "it's just slow", but it was quite a bit faster (usably fast) on the old dual 500MHz server, so I'm sure that there's something else going on here.

Network latency to the new server is 20-30ms higher than the old server, but (casually) throughput seems the same or higher, and I'm talking seconds, not milliseconds, so it ain't that.

#Comment Re: made: 2007-05-25 19:32:42.542442+00 by: meuon

The code caching stuff is important because of the insane levels of 'includes' in MediaWiki. It reads LOTS of files that go look at other files, that import XML to figure out how to read other files, to create the file that is interpreted into the HTML you see..

#Comment Re: made: 2007-05-25 20:24:42.488431+00 by: Dan Lyke

Ahhh.. So maybe it's that I don't have mod_php configured correctly, because I'd have figured that that'd do the same thing that mod_perl does.

And it is also possible that the hardware SCSI RAID array in the old server beats the IDE or whatever the disk bus is in the new one.

#Comment Re: made: 2007-05-25 20:47:42.171609+00 by: John Anderson

Late to the party, but yeah, 'iostat 5 5 -x' and see if the disk utilization is maxing out during one of those slow requests -- and then it's standard filesystem tuning tricks time: think about a noatime mount, look at whatever RAID configuration optinons you've got, etc.

Did the old server have more RAM? If it's doing lots of file reads, it's possible more of the data was getting into the OS file cache on the old machine; that can make a huge difference.

#Comment Re: made: 2007-05-25 21:29:51.554121+00 by: Dan Lyke

That's why I'm not a sysadmin, I just play one on the net. Thanks for that direction.

The only thing I can figure after that exercise is that I need to send Meuon some money for more RAM, because if it's simple system tuning it's gotta be going to swap or something. I watched it for 20 seconds at 1 second intervals, and neither I/O nor CPU were dramatic. A couple o' blips, but given over 10 seconds of load time that one of those samples would have given me something more dramatic than 14% hda utilization on one of those samples, and an average CPU that was often 100% idle, and never cleared 50%.

Ages ago I was writing some code that had two processes where one was reading and one was writing, and one wrote a length and then the rest of the structure and then a following string, and the other read the structure and then the following string, or some combination like that, and the performance was hideous. When I made the reads symmetric, performance hit memcpy() speeds.

This stinks of something like that happening between Apache and PHP.

#Comment Re: made: 2007-05-26 10:30:39.157754+00 by: meuon [edit history]

I was wondering if it was doing some type of DNS lookup or something.. Will sniff and see what is going on.

It'll have double the ram late next month when it's twin sister gets pulled from the rack.