Difference between revisions of "User:Gordon/Free Geek Wiki Upgrades"
| Line 30: | Line 30: | ||
====Stay on Etch and look for a newer backport==== | ====Stay on Etch and look for a newer backport==== | ||
This is the solution that will be obsolete in the shortest amount of time. | This is the solution that will be obsolete in the shortest amount of time. | ||
| + | |||
| + | ===Still slow?=== | ||
| + | * Convert most database tables to InnoDB if they are not already (this should be done regardless to prevent eventual corruption-related sadness) | ||
| + | * Investigate whether [http://www.danga.com/memcached/ memcached] would provide a performance benefit beyond APC, considering that Mediawiki may be using APC as an object cache as well as an opcode cache | ||
| + | * If the server is under load due to serving a lot of static content, investigate using something like [http://varnish.projects.linpro.no/ varnish] to efficiently cache and serve it (better than squid) | ||
Revision as of 11:25, 4 October 2009
Problem
The wiki is slow, especially when saving pages.
Solutions
Solutions are presented in increasing order of work and impact on the Mediawiki virtual server.
PHP opcode caching
Install a PHP opcode cache and give it 32-64MB of RAM. I use APC on umasswiki.com, APC has the advantage of direct support by Mediawiki.
Umasswiki.com is a wiki that gets 200K or more hits a month on a VPS with 360MB of RAM. I gave APC 48MB for its cache and noticed a very significant speed increase after it was installed. Looking at my stats, there is a 99.7% cache hit rate on my installation, and I am running other PHP apps in addition to Mediawiki. So, 48MB should be more than sufficient for APC on Free Geek's Mediawiki virtual server.
Having installed APC, I found that there was no need for memcached based on the load umasswiki.com experiences.
Upgrade Mediawiki
Free Geek is running on Mediawiki 1.12.0, which upon examination by Vagrant, appeared to be a Lenny package running on an Etch server. Either way, the current stable release is 1.15.1. 1.12.0 is very out of date and undoubtedly plagued with various security issues. As well, the virtual server should probably be upgraded to Lenny so that security fixes to PHP and MySQL will continue farther into the future.
I'm a fairly knowledgeable Mediawiki administrator (running UMasswiki since 2005, a personal wiki, converted the developer wiki to Mediawiki at my day job) and I have about 9 years of experience as a Debian user and system administrator. I run Debian on my VPS and am most familiar with it of all distros. Therefore, if the Free Geek staff are willing to trust me, I would be happy to work on upgrading the wiki software and server, possibly on a Sunday when few people are using it if that's possible.
There are 4 options:
Upgrade to Lenny (or beyond) and use Debian packages
This option is fairly self-explanatory. Easier to maintain, harder to keep up on critical patches to Mediawiki given the inability of Debian to quickly handle every one of the billion PHP-related security patches a month. Also, if anybody is interested in having me work on the wiki, I am least familiar with this method because despite using Debian for my servers, I always install Mediawiki by hand. I suspect that it is pretty easy to pick up, however.
Upgrade to Lenny and convert to a manual installation
This is more difficult to maintain (marginally -- it's actually pretty easy but not an apt-get only solution) but, if the will is there to maintain it, Mediawiki can be kept better up to date.
Stay on Etch and convert to a manual installation
This saves the work of upgrading the virtual server to Lenny.
Stay on Etch and look for a newer backport
This is the solution that will be obsolete in the shortest amount of time.
Still slow?
- Convert most database tables to InnoDB if they are not already (this should be done regardless to prevent eventual corruption-related sadness)
- Investigate whether memcached would provide a performance benefit beyond APC, considering that Mediawiki may be using APC as an object cache as well as an opcode cache
- If the server is under load due to serving a lot of static content, investigate using something like varnish to efficiently cache and serve it (better than squid)