TWiki Performance Cookbook
So, you installed TWiki, and you love the features. But you are worried about performance, and scalability. What can you do about it?
Remember, TWiki is used in huge
sites (one example has 5,000 users and 120K topics, all served off a single
server machine). So there is a lot of scope....
Fast Server Platform
The faster your server is, and the more memory it has, and the faster the disks, the better. Sounds a bit obvious, but you'd be surprised how many people think it's a good idea to run a public website off a 233MHz P2 with 128MB RAM.
As a general rule of thumb, a 2.4GHz P4 with 2GB RAM and a standard disk should be enough for a company of 30 to use the TWiki for everything (task management, business management, the lot).
If you have lots
of available memory, you may get improved performance using
Fast Web Server
Make sure you have tuned your webserver to get the maximum out of it. If you are using Apache, http://www.apache.org
has a lot of performance tips and benchmarking advice.
The first and most obvious thing you can do is to run TWiki with a perl accelerator. These are webserver modules that keep perl cached in memory, so that each new request doesn't have to load the whole perl interpreter each time. There are two accelerators that have been widely used with TWiki:
Both of these work.
is much easier to set up.
is closer to Apache, and may give better performance. There are some reports of issues with
locking up on large webservers. There are known issues with some plugins with
is probably the most widely used of the two, and is likely to be installed in your webserver already.
You can accelerate all of the TWiki scripts, except
There are other options, such as FastCGI, but there are no records of successful installations using these.
As shipped, TWiki has an awful lot of features. It's configured as a "general purpose wiki" which means it isn't tuned for any specific application. As such, there are quite a few compromises, some of which can negatively affect performance.
- Localization (I18N, user interface internationalisation) can have a major impact. Turn it off if only English speakers will be using your site.
- Hierarchical webs require many more searches to be done, and can adversely impact performance.
- Auto-attach is a really nice feature, but only used on a minority of sites. Turn it off unless you really need it.
- Use a simpler skin. the default
pattern skin is featureful, but those features cost you in performance. By selecting a simpler skin, such as
classic skin, or even dropping back to the default templates, you can gain a few ms.
- Default left bar web lists in
pattern skin shows coloured squares for each web. This is an example of an expensive, and probably pointless, search.
- In fact, anywhere in the templates where you see SEARCH should ring alarm bells.
- Switch off plugins. Disable any plugins (in
configure) that you are not using. Each enabled plugin creates a load, even if you aren't using it.
- If you don't need sessions, then don't use them. If every client on your site has a unique IP address, and you are using ApacheLoginManager, you can turn sessions off. Check first that none of your plugins require sessions!
- If you don't need permissions, then don't use them! Remove (comment out) permissions from webs and topics (see TWikiAccessControl).
Organise your data
You can improve access times by using the TWiki "webs" feature to organise your data into separate domains. By breaking down data this way you can speed up searches, and often make them more effective. On the flip side, having too many webs can have a negative impact on performance. A reasonable rule of thumb is to try and organise your data so that each web won't grow beyond ~ 1000 topics.
Another thing that people often miss is the need for regular gardening
. You need to maintain your data, otherwise it becomes impossible for users to use it. Develop local wiki experts, and make sure they have time to refactor content. Remove old, stale content, while also bearing in mind that URI's people have bookmarked shouldn't change if you can avoid it.
This is a work in progress; please feel free to correct/extend.
- You may be able to use plugin caches, such as VarCachePlugin, effectively. Make sure you know what is available.
-- Contributors: AntonAylward
I have been experimenting with
on my Linux server.
The default size of my ramdisk is 16Meg and all of TWiki, the
will fit in there. I could fit in the
but I'm unwilling to.
My first test was using a ramdisk for the session store. Under Dakar this is easily configurable at run time so I could do A/B comparisons. It is easy to set up a
directory for the session files and even if the machine reboots and fails to setup and mount the ramdisk things still function.
It is technically possible to copy all of TWiki onto the ramdisk and run from there is the
are small enough to fit, but it is risky. If the machine crashes the changes will not get copied back to permanent store.
However a setup that on boot or startup copies the binaries and libraries to ramdisk is feasible.
of this arangement are clear. The cons
are more subtle.
Late model UNIX/LINUX does not have a fixed size buffer cache. Memory is allocated dynamically between processes and disk buffering according to demand. On the whole the algorithm is a good one. Using a Ramdisk only makes sense if it does a better job than that algorithm.
If the loss of available memory to the ramdisk causes process to page or swap, that in turn puts a load on the buffer cache and disk activity. More disk activity, expecially paging, kills perfromance.
So don't use ramdisk unless you have lots of available memory.
- 09 Nov 2005
Keep in mind how FS caching working is OS, filesystem and mount options dependent. Please try not to make blanket statements/assumptions regarding file system read caching. -Brian (In my environment the largest benefit of file system buffering is optimization of write performance.)
- 12 Nov 2005