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. Petko _______________________________________________ pmwiki-users mailing list [email protected] http://www.pmichaud.com/mailman/listinfo/pmwiki-users
