• View
• Edit
• History
• Attach
• Print
• Backlinks

PerformanceComparisons

Question

Is your wiki sometimes slow? How can you get better performance out of your wiki installation?

Description

It seems that different site administrators get varying degrees of speed performances from their PmWiki installations. Some admins report that their wikis seem unusually slow at times, while others never have this problem at all.

The purpose of this page is to allow administrators to compare set-ups and performances. If you run a wiki that consistently gets great performance – or, if your wiki installation seems to slow down frequently, please tell us how you have your wiki set up. Some details to include are: OS, webserver, PHP version, PmWiki version, RAM, and a list of recipes being used, and include any other information that seems pertinent.

Details

Details for pmwiki.org:

• OS: Fedora Core 2, Linux 2.4.20 kernel (VPS environment)
• Webserver: Apache 1.3.33 w/mod_auth_passthrough, mod_log_bytes, mod_bwlimited, mod_ssl
• PHP: 4.3.11, Apache API
• PmWiki: pmwiki-2.2.0-beta66
• Approximate number of pages on site: 3600
• RAM: 512MB
• Recipes used: various (depends on group/page)
• Performance Notes: Sometimes it's really fast. Other times it crawls. The times that are slow seem to correspond to times when the system has a lot of other activities going on (e.g., daily maintenance upgrades) or when the mailing lists are extremely active. Pm has been actively monitoring PmWiki performance on this system and thinks the primary culprit is filesystem related.

• OS: Windows 2003 SP2
• Webserver: IIS 6
• PHP: 5.0.5.5
• PmWiki: 2.1.5
• RAM: 1 GB
• Recipes used: blocklist2.php, dictindex.php, pagetoc.php.
• Other information: It runs on a machine dedicated server in a professional hosted rack.
• Performance Notes: Wiki generally performs slow. Sometimes surprisingly fast - but other times it runs unbearably slow. Have not been able to make any connection between performance problems and anything that I'm doing. This has been going on since day 1, before I added all the cookbook scripts. Other site subsystems like the vbulletin forum on http://debat.ateist.net (same server) runs blazingly fast!
• My opinion: I have come to the conclusion that performance-wise, pmwiki is simply slow pr. design. And it will only grow worse when new recipes is added. What is needed, is a redesign where the page and the affected pages are generated when inserting/modifying pages. And not when browsing. This would make the wiki system much faster, regardless how many recipes you add...

• OS: Red Hat Linux Version 2.4.21-4.0.1 elsmp
• Webserver: Apache 1.3
• PHP: 4.3.11
• PmWiki: 2.1.3
• RAM: ???
• Recipes used: blocklist2.php, buildforms.php, commentboxstyled.php, forumstyled.php, newpageboxplus.php, pageattic.php, pmcal.php, pmwikidraw.php, quicktime.php, ryevote.php, skinlist.php, tylepage.php, swf.php, totalcounter.php, urlapprove.php, webadmin.php, wmplayer.php, XSiteInfo.php
• Other information: My hosting is through Godaddy.com, so I'm not sure what the RAM is, I'll list it when I find out (I'm sure it's decent)
• Performance Notes: Generally performs about average, sometimes surprisingly fast - but other times it runs unbearably slow. Have not been able to make any connection between performance problems and anything that I'm doing. This has been going on since day 1, before I added all the cookbook scripts.
• Update: I have dropped godaddy hosting and switched to a VDS environment. All speed problems have vanished, and I have not had any problems since (about 1 month so far). Before, I was convinced that the problem was PmWiki, because my HTML pages on the same site came up instantly, while wiki pages took forever... but, for whatever reason, my wiki runs very fast now, and I've installed a good number of recipies (my config.php file is about 19KB). It might be worth mentioning that I'm using eAccelerator now, so that may be helping.

Details for ApfelWiki:

• OS: Linux (on SUN)
• Webserver: Apache/2.0.54
• PHP: PHP/4.3.10-16
• PmWiki: 2.1.5
• Approximate number of pages on site: 3000
• RAM: unknown
• Recipes used: backup_pages.php, rename.php, postitnotes.php, autorestore.php, categoryindex.php, jumpnsearch.php, missingwikipages.php, stubpages.php, deadendpages.php, icalexport.php, e-protect.php, dictindex.php, favorites.php, blocklist2.php, numberofsites2.php, newpageform.php, complexvote.php, simuledit, yahoosearch.php, wikimarkupconversion.php, totalcounter.php, titledictindex.php, tellafriend.php, extendmarkup2.php, skinchange.php, showrandomarticle.php, sectionedit.php, rss.php, markfordelete.php, mailform.php, imgpopup.php, attachlistenhanced.php, commentboxstyled.php, pmwikiautoupdate.php, pagetoc.php, pagecount.php, wikilog and some special ApfelWiki-Receipts.
• Performance Notes: Some times it works great, sometimes it really slow. We had two major crashes and our hoster reclamed too many resources using. Neither him nor we could find a reason for this. Actually looking again at our receipts.

• OS: Linux (Debain Sarge)
• Webserver: Apache 2.0
• PHP: 4.3.4 CGI/FastCGI (actually it's using CGI)
• PmWiki: 2.0.13
• Approximate number of pages on site: multiple sites, few if any >50
• RAM: 256 MB
• Recipes used: Mostly no recipes. No recipes that require processing.
• Performance Notes: Runs mostly well, sometimes it seems to hang. The system recently acquired an unfortunate tendency to thrash (i.e. too much RAM requested by the active processes); I'm not yet sure why this is so, PmWiki isn't the only possible culprit. (The system is running a whole bunch of software, not just PmWiki, so this all may be totally unrelated to PmWiki.)

One thing I can confirm: sometimes PmWiki seems to take ages to complete; however, it usually comes around to serving something (though that may take a minute or so).

• OS: Windows 2003
• Webserver: IIS 6
• PHP: 4.3.9
• PmWiki: 2.1.11
• Approximate number of pages on site: 1500
• RAM: 512Mo
• Recipes used: searchterm, forum styled, sidebar,newpageboxplus, in fact a minimum as possible
• Performance Notes: As others people mention, sometimes the wiki is very slow. With certain option like rapid-failed detection of IIS6, the site return regularly "Site unavailable" error and some linked others errors about IIS restart. The server host also 7 others intranet websites, but PMwiki is alone to run PHP.

• OS: Windows 2003
• Webserver: Apache 2.0.54
• PHP: 4.4.1
• PmWiki:2.1.11 Farm with 10 fields
• Approximate number of pages on site: 2600, the bigger field count 850 pages
• RAM: 512Mo
• Recipes used: many chartdir.php, commentboxstyled.php, enablehtml.php, expirediff.php, forumstyled.php, grouplist_stap.php, imagemap.php, listdir.php, newpagebox3.php, openwindow.php, pagetoc.php, pmcal.php, postitnotes.php,

 rename.php, renamehelper.php, searchterms.php, sourceblock.php, VisitorsLogging.php,
 wikilog-i18n-en.php, wikilog.php, XToDo.php

• Performance Notes: Seems much faster than the server with IIS (see upper) and the slowness seems less important. I dont find actually any link with the activity.

° OS: X (10.4.8) iBook G4 ° Web Server: Apache/1.3.33 (Darwin) PHP/5.2.0 ° Serving from: either - Sites directory, or WebServer/Documents directory. ° PmWiki Version: 2.1.27 &(both) 2.2.0-beta29 ° RAM: 512 ° Approx. number pages: 250 ° Performance notes: Sometimes crawls (especially from release notes, FAQ and Change Log links, Yet I removed these pages and still had up and down speed variables), other times its satisfactory.

• OS: Windows XP Professional
• Webserver: Apache 2.0.55
• PHP: 5.0.5
• PmWiki: pmwiki-2.1.27
• Approximate number of pages on site: 10500
• RAM: ?
• Recipes used: tabtable, authuser, imagemap, includesite, commentboxstyled, forumstyled, wikiform, breakpage, extendmarkup
• Performance Notes:
  • PmWiki has been fast for a long time, but recently it has slowed down to a crawl.
  • In addition to the pages it serves a large number of files too, and due to Umlaut problems under Windows this has to be done via indirect download with an additional performance impact.
  • I checked the Apache error.log and found a number of fatal errors (example: FATAL: erealloc(): Unable to allocate 98304 bytes), followed by restarts. (This happens about 40 times a day.) I assume the server has too little RAM for my purposes, but have been unable to confirm this yet.
  • The server usually serves around 5000 pages a day, running a corporate intranet.
  • Processor load peaks at a solid 100% around noon (with long response times or even errors), dropping gradually to an average of maybe 20% by 1800 hours.
  • --Henning October 08, 2007, at 10:48 AM

Add your details

Comments

The following test script will possibly help you discover the amount of memory installed in your server:

if (strtoupper(substr(PHP_OS, 0, 3)) == 'WIN') {
  echo 'Wrong platform for this test';
} else {
  echo '<pre>';
  system('free');
  echo '</pre>';
}

Divide the "total" by 1024 and you will see the approximate number of MiB installed minus some amount that is not available to the kernel. -Hagan

See Also

There are several recipes designed to help performance:

• Fast Backlinks? - probably obsolete in 2.1.x
• Fast Search - probably obsolete in 2.1.x
• Output Compression
• Search Index? - probably obsolete in 2.1.x

Contributors