[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.
Petko
More information about the pmwiki-users
mailing list