eAccelerator, APC, and MediaWiki

software development

#1

Hi all. My install of MediaWiki is running quite a bit slower than I’d like. I’ve looked around at some of the posts that suggest that it’s possible to get eAccelerator and APC running on Dreamhost, and was wondering if anyone has had good experiences running either of these with MediaWiki on Dreamhost? Would anyone make a recommendation of one versus the other?

Any other suggestions for getting better performance out of MediaWiki on Dreamhost are welcome too.

Thanks!


#2

Has anyone else found ways to speed up MediaWiki under Dreamhost? LIke smunson, I’m finding it a bit slow.

Cheers.


#3

When I tried a few months ago, eAccelerator definitely made a noticeable improvement in MediaWiki performance, but it wasn’t enough to make it a pleasure to use. The wiki really wants you to throw a lot of processor at it, and that’s just not going to happen in a shared hosting environment. One of my friends even had it running on a dedicated server from another host and still wasn’t thrilled with it despite spending a huge amount of time tweaking for performance.

If you don’t need all that MediaWiki offers, I’d recommend finding something a bit lighter instead. There are quite a few wiki projects out there, with varying degrees of similarity to MediaWiki and varying levels of performance. Wiki Matrix is a good way to compare different packages.


#4

Thanks misoman.

I’ve chosen WikiMedia because I want to be able to do semantic markup, which Semantic MediaWiki (http://meta.wikimedia.org/wiki/Semantic_MediaWiki) allows. There aren’t many wikis out there with such a feature, unfortunately. I’ll put up with some speed deficit if that’s what it comes to.

Do you know of any useful docs on eAccelerator on Dreamhost?


#5

It’s been a while since I did the install, but I think I pretty much followed the same procedure outlined here:

http://blog.robinz.info/archives/2006/02/15/how-to-install-eacceleartor-on-dreamhosts-host/

There may have been some tweaking necessary that I’m forgetting, so if I have time tomorrow I’ll try a fresh install on one of my spare domains to remind myself if there were issues not covered by that article.


#6

Hmm. Compiling and installing a new PHP seems a lot of messing about. Does anyone know if the PHP.ini settings can be overridden locally somehow, to enable running eAccelerator with Dreamhosts’s PHP?


#7

As far as I’m aware, no. eAccelerator needs to be compiled in your local environment anyways, as it’s not currently installed on the DH servers by default.

You could always offer to have someone install it for you I suppose, if you really feel it’s that difficult. But really, if you just follow the wiki step-by-step, it works out nicely :wink:


#8

You’ve at least set up FastCGI, haven’t you? Short of using something like eAccelerator or APC (which would also require a custom PHP install), FastCGI’s pretty much your only speedup option (unless you want to dig into the MediaWiki codebase and optimize it for your specific needs).

FastCGI won’t make MediaWiki much faster, but it should slightly decrease response time.

A custom install of PHP is usually fairly easy to set up, so don’t write it off just because it sounds like a pain. If you follow the excellent instructions in the wiki, things should go pretty smoothly.


#9

Thanks for the info, guys. Very helpful.

I was a bit reluctant to install PHP because I don’t know much about it, which I thought would make troubleshooting difficult.

I was half-right about that. I’ve got a PHP install working OK under straight CGI, but eAccelerator doesn’t seem to be loaded (no ref to it when calling phpinfo();). I’ve got extension_dir and all the necessary eaccelerator.* options set in php.ini. Any thoughts?

I thought I should try and get eAccelerator working under plain cgi first. But out of interest I can’t so far get my own PHP installation to work under FastCGI at all (fcgi does work fine with the /dh one). No cgi processes are spawned, and I get a ‘FCGI: incomplete headers (0 bytes) received from …’ error.


#10

Correction – I recompiled eAccelerator with some changes, and the extension does load now. But phpinfo gives me for eAccelerator:

Caching Enabled false
Optimizer Enabled false

… which seems to imply it’s not doing anything.

And I still can’t get my own PHP to work under FCGI.


#11

Another correction – I now realise on reading the docs that eAccelerator won’t work under standard cgi. So I have to get FastCGI working.

So far, I’ve followed the instructions at http://wiki.dreamhost.com/index.php/PHP_FastCGI. These work fine for dh’s php, but not for my version.


#12

Check to see if your build of PHP has FastCGI enabled.

/your_custom_install_path/php -v

After the version number it gives you, it will say either (cgi) or (cgi-fcgi). If it’s not enabled, you can run configure again and set it:

./configure --enable-fastcgi
make
make install


#13

Thanks misoman. That was the issue.

There’s something pretty strange about this stuff on Dreamhost though, as some of my requests work fine (with eAccelerator doing the caching as shown in its log file), but others (ie. for the exact same URLs) hang for ages and then give me a 500 server error.

Even more odd, requests to my MediaWiki instance always get the 500 error, whereas a test.php and my Gallery installation both work about half of the time.


#14

Hmm. Some things you could try:

  1. Changing the amount of shared memory eAccelerator uses. I think, though I don’t know this as fact, that DH servers each differ a bit in how much memory a process is allowed to allocate. You can find out how much your server offers by:

cat /proc/sys/kernel/shmmax

It will display in bytes. For me, it’s about 32MB. You can change eAccelerator’s default setting for eaccelerator.shm_size to the number of megabytes you want to use.

  1. You could change the settings for eaccelerator.keys | sessions | content to use only disk (disk_only) or shared memory (shm_only) to see if there’s a caching problem with one or the other.

For example,

eaccelerator.sessions = “disk_only”

Or just a blanket eaccelerator.shm_only = “0” which disables the disk cache for everything.

  1. Maybe there’s something screwy with the compressor. You could try disabling compression with eaccelerator.compress = “0”.

Anyway, those are the things that come to mind at the moment, but I don’t know whether any of them would be related to your problems.


#15

OK, I’ll look into all that. I appreciate the pointers, thanks.

Oddly, the problem does turn out to be MediaWiki-specific after all. If go to my other urls after I’ve been to my media wiki, they fail sometimes. Something is dumping core in my MediaWiki directory after a browse there, too.

But if I leave it a while, and avoid media wiki altogether, everything’s fine (and quite a bit quicker than before). So I’ll have to look around to see if I can find any eAccelerator/MediaWiki-specific info.

Anyway, I’ve spent as much time on this today as I dare. Cheers.


#16

I can’t remember for certain, but it’s possible I may have disabled some or all of MediaWiki’s built-in caching when I installed eAccelerator previously. That’s probably a better place to start than my previous suggestions.

If you want to try disabling all of MediaWiki’s built-in caching, in LocalSettings.php you’d need the following:

$wgMainCacheType = CACHE_NONE;
$wgMessageCacheType = CACHE_NONE;
$wgParserCacheType = CACHE_NONE;
$wgCachePages = false;