Recent Changes - Search:
Cookbook /

PerformanceComparisons

Summary: Page to share site setups and performance
Version:
Prerequisites:
Status:
Maintainer:
Categories: SystemTools, Administration

I'm not sure if there might be a better place for this page, so feel free to move it if it seems inappropriate here - Phil S.

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.3.38
  • 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.
Site: princetonweb.org
  • OS: Linux-Apache
  • Php: 5.3 - Zlib disabled (off or 0) - Gzip enabled in root htaccess file
  • Number of pages: 30,000 plus
  • PmWiki: Latest
  • Recipes used: various
  • Performance Notes: Always top speed - no relation to number of pages, even when added a thousand at a time through direct upload. For an idea of how the ini and htaccess root files are configured, after removing backslashes, download http://\princetonweb.\org/Downloads/Phpini.htm and http://\princetonweb.\org/Downloads/htaccess-file-for-root.htm. See bottom of page for just the htaccess gzip code so as not to have to bother with the remainder of the htaccess file. If you don't have access to an htaccess file, you may be able to get the same effects by going here Compressed Page Store. Just remember to turn off zlib, if you can, since they conflict; of this I am sure.
Site: http://wiki.ateist.net
  • 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...
Admin: Phil S.
  • 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
  • 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
  • OS:
  • Webserver:
  • PHP:
  • PmWiki:
  • Approximate number of pages on site: 3600
  • RAM:
  • Recipes used:
  • Performance Notes:

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

This code, when added to the root htaccess file where zlib has been turned off in the php ini file, will speed your site remarkably. At least it worked with my setup, and I have a 30,000 page mega-site and been looking for speedups for years. With no relation to wiki.d size, or page number, this code opens the door for a million page site. Here's the page I got it from \http:\//www.warpconduit.net\/2010/10/23/enabling-gzip-compression-of-php-css-and-js-files-without-mod_deflate/
#Compress
SetOutputFilter GZIP
</Files>
<ifModule mod_gzip.c>
mod_gzip_on Yes
mod_gzip_dechunk Yes
mod_gzip_item_include file .(html?|txt|css|js|php|pl)$
mod_gzip_item_include handler ^cgi-script$
mod_gzip_item_include mime ^text/.*
mod_gzip_item_include mime ^application/x-javascript.*
mod_gzip_item_exclude mime ^image/.*
mod_gzip_item_exclude rspheader ^Content-Encoding:.*gzip.*
</ifModule>
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^(.*\.js) gzip.php?type=js&file=$1
RewriteRule ^(.*\.css) gzip.php?type=css&file=$1
This code is for caching using the htaccess file; you can do it in the root htaccess file, or using FastCache.

##Caching
<ifModule mod_headers.c>
# Turn on Expires and set default expires to 3 days
ExpiresActive On
ExpiresDefault A259200
# Set up caching on media files for 1 month
<filesMatch ".(ico|gif|jpg|jpeg|png|flv|pdf|swf|mov|mp3|wmv|ppt)$">
ExpiresDefault A2419200
Header append Cache-Control "public"
</filesMatch>
# Set up 2 Hour caching on commonly updated files
<filesMatch ".(xml|txt|html|js|css)$">
ExpiresDefault A7200
Header append Cache-Control "private, must-revalidate"
</filesMatch>
# Force no caching for dynamic files
<filesMatch ".(php|cgi|pl|htm)$">
ExpiresDefault A0
Header set Cache-Control "no-store, no-cache, must-revalidate, max-age=0"
Header set Pragma "no-cache"
</filesMatch>
</ifModule>
#<IfModule mod_win32.c>
#AddHandler application/x-httpd-php .php .html .htm
#</IfModule>
#<IfModule !mod_win32.c>
#AddHandler application/x-httpd-php5 .php .html .htm
#</IfModule>
RewriteEngine On
##compress text, html, javascript, css, xml:
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/flat
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/x-javascript
AddOutputFilterByType DEFLATE image/gif
AddOutputFilterByType DEFLATE image/jpg
AddOutputFilterByType DEFLATE image/jpeg
AddOutputFilterByType DEFLATE image/png
AddOutputFilterByType DEFLATE image/bmp

-Jagtig

See Also

There are several recipes designed to help performance:

Contributors