[pmwiki-users] A save-and-view button

Petko Yotov 5ko at 5ko.fr
Sat Feb 6 13:37:04 CST 2010

On Saturday 06 February 2010 19:14:06, Randy Brown wrote :
> This raises a question that I've been meaning to ask anyway: does adding
>  custom conditional tests or custom page variables slow PmWiki's
>  processing? If it doesn't slow my already slow wiki, I can think of all
>  sorts of ways I might want to use them.

This one doesn't. :-)

Conditionals, MarkupExpresisons, or custom markup, which read pages from disk 
do slow the processing - eg. those calling the functions PageVar, ReadPage, 
RetrieveAuthPage, PageTextVar, CondAuth...

Other stuff that slows down / speeds up a wiki :
* Pagelists, more than the required ones. For example, a menu/sidebar with a
  bulletted list is times faster than a menu populated by a pagelist -- and as
  a menu doesn't change often, it is usually better to update it by hand.
  + Adding a group=Main or a name=Main.*-Talk filter to a pagelist speeds it.
  + Wikitrail from a pagelist is slower than normal wikitrail, like the menus.
* $EnablePageListProtect = 0; speeds significantly pagelists. Look at the docs
  though, before setting this: http://pmwiki.org/wiki/PmWiki/PagelistVariables
* Including other pages, and PTVs from other pages, requires to open the disk
  files of the other page -- so use sparingly. If you don't often change a
  site header/footer, it will be faster to have the content in the skin
  template instead of in wiki pages.
* Some recipes like total realtime visitor counters read&write to disk files
  on every page view -- that could be significantly slower. Besides the stats,
  if a recipe manipulates session data, a session file is also read/written.
  Reading a file takes time, writing to a file usually takes much more time.
* Using too many recipes requires to open all their cookbook *.php files,
  which adds some milli-seconds.
* Using RewriteRules/CleanUrls is slightly slower than not using it.
* $EnableIMSCaching = 1; makes everything faster, in the period between one
  edit and another edit (in the whole wiki) -- so if you have such long
  periods and many visitors between them, it may be useful.
* Loading javascripts, puctures and counters from external websites often 
  makes a site "feel" slower - stuff like Ads or Google Analythics.
* Loading external content is slower - like inline RSS feeds, Flickr/Twitter
  updates, Weather, Maps etc. -- unless the recipe caches the remote data for
  a while and displays the cached version to many visitors.
* On my experience, PmWiki on PHP 5 runs noticeably faster than on PHP 4.
* (I may have forgotten something.)

There are recipes (FastCache...) which claim to speed the processing and the 
wiki should run faster for non-logged-in visitors. 

The SQLite PageStore recipe was reported to dramatically speed up a wiki 
including pagelists -- it is very likely faster, but I haven't personnally 
used it on a wiki with hundreds of pages, hundreds of visitors a day and many 
editors, so I still consider it experimental.

If you run a dedicated hardware server, you can do even more optimizations 
(and if you're either a black-belt admin with a beard, or have enough money to 
hire me :-).
* Use a local harddisk rather than network storage.
* Use a faster filesystem like Reiser4 or a less-CPU-intensive one like JFS.
* Use fast SSD hard-disks -- even a Flash memory card with the program files
  could improve speeds (only use for limited, rarely modified files, not for
  wiki.d or uploads; needs testing - speed could also be worse).
* Use not Apache but a smaller/faster http server like Nginx.
* Use PHP with FastCGI.
* Use a PHP cache like APC. http://en.wikipedia.org/wiki/PHP_accelerator . 
  Earlier this week, Facebook announced a new faster PHP runtime/webserver.
* Copy all the program files, skins, css... into the RAM of the server and run
  the wiki from there.


More information about the pmwiki-users mailing list