installation1Add my vote for this tag performance1Add my vote for this tag create new tag
, view all tags

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 ramdisk.

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. speedycgi is much easier to set up. mod_perl is closer to Apache, and may give better performance. There are some reports of issues with speedycgi locking up on large webservers. There are known issues with some plugins with mod_perl. mod_perl 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 configure.

There are other options, such as FastCGI, but there are no records of successful installations using these.

Disable features

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.

Intelligent caching

  • You may be able to use plugin caches, such as VarCachePlugin, effectively. Make sure you know what is available.

This is a work in progress; please feel free to correct/extend.

-- Contributors: AntonAylward, SvenDowideit, CrawfordCurrie


I have been experimenting with ramdisk on my Linux server.

The default size of my ramdisk is 16Meg and all of TWiki, the /bin, /lib, /templates will fit in there. I could fit in the /data and the /pub 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 /tmp/ramdisk 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 data/ and pub/ 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.

The pros 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.

-- AntonAylward - 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.)

-- BrianGupta - 12 Nov 2005


Edit | Attach | Watch | Print version | History: r8 < r7 < r6 < r5 < r4 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r8 - 2006-04-25 - SamHasler
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.