PHP caching and optimization: Difference between revisions

From Meta, a Wikimedia project coordination wiki
Content deleted Content added
No edit summary
JamesDay (talk | contribs)
Summary of what we're using now and what we tried and had problems with
Line 1: Line 1:
Wikimedia currently uses Turck MMCache for PHP caching. PHP-Accelerator gave some problems when it didn't get updates quite right, such as adding a new method to a class. Alternative PHP Cache was also tried and gave a variety of problems but that was some time ago. [http://mail.wikipedia.org/pipermail/mediawiki-l/2004-June/000641.html (6 June 2004 post on which this is based)]


== APC ==
== APC ==
http://apc.communityconnect.com/
http://apc.communityconnect.com/

Revision as of 10:56, 14 July 2004

Wikimedia currently uses Turck MMCache for PHP caching. PHP-Accelerator gave some problems when it didn't get updates quite right, such as adding a new method to a class. Alternative PHP Cache was also tried and gave a variety of problems but that was some time ago. (6 June 2004 post on which this is based)


APC

http://apc.communityconnect.com/

Caches compiled PHP scripts to avoid the overhead of parsing and compiling the code every time pages are loaded. Wikipedia has used it off and on; but more off than on because we've had some problems in the past with mysterious corruption of the cache files, etc.

I've just upgraded to a recent CVS version, we'll see how it goes... (It was still bumping up our load and not helping very much. It still messes up the rdf generation.)

PHPA or Zend Optimizer

  • Use Zend Optimizer? PHPA? (have we tried using the Zend Optimizer or PHPA?)
    • These two projects are not free software (though they are free of charge), which makes me rather leery. Although since they are theoretically just drop-in accelerators and are not required, we would not be made dependant on closed-source software by using them for a boost. --Brion VIBBER
    • While I too wish it was OSS, I don't see what the loss is in at least giving them a shot. If they change their license in the future, then we are (at the very least) no worse off than we are now. Anything to help the performance is horribly needed. Wikipedia is nearly unusable during the daytime hours, and any kind of solution is dearly needed. --Marumari
      • I'll give them a shot, see if they're less problematic than APC. --Brion VIBBER

I've installed PHPA, we'll see how it goes. --Brion VIBBER 21:34 20 Mar 2003 (UTC)

Comparing the 15 minutes before installation with the 15 minutes after, using the English Wikipedia logfile:

20030320211530 |20030320213030| 20030320214530
Before cutoff: 2689 pages served, runtime 14463.218 seconds
That's 2.98777777777778pages/sec served
At avg time per page of 5.37866046857568

After cutoff: 4169 pages served, runtime 8020.671 seconds
That's 4.63222222222222pages/sec served
At avg time per page of 1.92388366514752

Load average has also fallen somewhat, from 15-20 to 7-10 range. I'm reasonably happy with it so far, hopefully it won't have any other problems. (Note: I've since corrected the pages per second rates above, they was initially calculated with an incorrect ratio.) --Brion VIBBER 21:51 20 Mar 2003 (UTC)

Well, that works out to a 55% percent increase in throughput and a 64% decrease in load time. If it doesn't break anything, it seems like a big win to me. --Marumari 22:08 20 Mar 2003 (UTC)

That's only a few minutes -- during which traffic type can change -- so it's not a reliable data set, but it's a good sign. :) --Brion VIBBER 22:11 20 Mar 2003 (UTC)


Okay, 90 minutes on either side:

20030320200030 |20030320213030| 20030320230030
Before cutoff: 19682 pages served, runtime 53717.1640000001 seconds
That's 3.64481481481481pages/sec served
At avg time per page of 2.72925332791383

After cutoff: 24891 pages served, runtime 59320.2220000005 seconds
That's 4.60944444444444pages/sec served
At avg time per page of 2.38319963038851

And compare with the same time period yesterday, since there's a dropoff in traffic over this period and we need to correct:

20030319200030 |20030319213030| 20030319230030
Before cutoff: 20774 pages served, runtime 69988.5320000001 seconds
That's 3.84703703703704pages/sec served
At avg time per page of 3.36904457494946

After cutoff: 21771 pages served, runtime 66441.7349999997 seconds
That's 4.03166666666667pages/sec served
At avg time per page of 3.05184580405125

Yes, that looks like a bigger relative improvement than just the traffic dropoff, which is definitely nice. (Also note that the runtime figures in the wiki log don't directly show script load time, which is one of the principal things that PHPA helps with.) --Brion VIBBER 23:16 20 Mar 2003 (UTC)


Turck MMCache

http://turck-mmcache.sourceforge.net/

Claims to be a bit faster than PHPA, a bit slower than Zend Accelerator, and is GPL. May want to consider trying this.

Now, the Fastest GPL Accelerator in GPL. (see above benchmarks)

Can't say I've ever heard of it. It certainly might be worth trying. Perhaps we could also contact Zend and see if they would offer us a free license of their optimizing software? --Marumari 19:41 11 Apr 2003 (UTC)
How nice is it! It faster then PHPA now :)