Foswiki on GitHub is open for business! Next release meeting: Monday October 13, 1300Z

Performance Supplement

Foswiki Performance Considerations

Server based optimizations are good and might be necessary but may not be the final bottleneck. Once done the client side communication between the browser and server will become central.


An easy method to get some reliable data about Foswiki performance from an end user perspective is by using tools which measure the time to build up the called page. For Firefox this functionality is available as part of the Firebug plugin (also available for Internet Explorer, or Opera as FirebugLitePlugin but without network analysis). Chrome and Safari have this functionality already builtin ( Control the current page > Developer > Javascript Console > Resources and Develop > Show Web Inspector respectively).

(wip Some words about Benchmarking possibilities) Here are pages listing tons of related tools:

An analysis about potential impacts on the page load time:


Foswiki Standalone Architecture (FSA)

On the server side the FSA architecture is the foundation for speed optimizations. There is ongoing work to further improve it. As a result the following extensions will profite from this architecture and are the base to reduce Foswiki overhead:

These contribs allow to get rid of re-loading and re-compiling any feature on server side which might be required on a called page upon each single call, which is the case when working with standard CGI.

Database Considerations

Since a default Foswiki installation uses a text based database (flat files), it is rather necessary to have local disks with good response times instead of another round of network based calls. The search speed is considered to be good enough for several thousand of topics but becomes a bottleneck when using thenths or hundred thousands of files.

The following contribs are available to speed up access to the data base especially for search operations:

Caching Macros

This Plugin caches Foswiki macros in selected topics for faster page rendering.

Other Server Side Considerations

VarWEBLIST overhead

WEBLIST can be quite slow. See BestPracticeTip20 for advice on replacing WEBLIST with a topic holding a static version of the output from this macro.

Session Expire After

Consider setting {Sessions}{ExpireAfter} to a negative number while also enabling the session clean up script tools/ via a cron job. Please find more details in the description for {Sessions}{ExpireAfter} which is part of configure.

TOC Page Reload

If the page is fully reloaded while just using the %TOC% macro, then have a look at this support question.


(Have some general statements about how the amount of Extensions influences the general Foswiki performance. Put a table listing Extensions which speed up and Extensions known to operate not really quick or to cause speed issues (TreePlugin, HolidaylistPlugin, etc.) in certain situations/combinations.)

For some extensions possible performance issues should be considered.

Load Caused by Spiders

Client Side Communication

Modern browsers are all using a cache which holds data in the memory but also on the local disk. This cache should be active and not turned off. It will also cache data retrieved via HTTPS (Firefox 2.x had issues with it) unless this is actively prevented due to special security considerations.

To even further minimize calls and the necessary data amount the apache modules mod_expire and for compression mod_deflate should be active. Module expire can e.g. take care of pictures, javascript and css files, mainly static files which are changed less frequently. Module deflate then could handle everything which is not already compressed. Both modules are worth to be active in most cases.


Apache Module Expire

This module will completely avoid a call of valid files from the browser for any files marked with a time stamp for validity. Depending on configuration the length of validity can be configured but even 1 day or just a few hours will have an effect. Pictures are usually pretty static and do not need to be re-verified regularly, so they are ideal candidates for mod_expire. Module expire will guaranty that the browser is not even asking on a normal page call to re-check if the file might have been changed within the valid time period. This reduces the amount of basic calls and has a higher effect if response times are longer.

Apache Module Deflate

Since computers are pretty quick, the CPU overhead caused by compression on server side is usually much less compared to the advantages gained by sending small files over the network. This is "normally" even the case when using encryption on top of compression. Hence enabling compression should be considered and makes sense with HTTPS as well.


For the Client side the BrowserBoosterPlugin is available to improve performance in case of higher network latency or to work around Firefox 2 issues.
Edit | Attach | Print version | History: r11 | r9 < r8 < r7 < r6 | Backlinks | View wiki text | Edit WikiText | More topic actions...
Topic revision: r8 - 09 Jan 2011, PaulHarvey
The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. see CopyrightStatement. Creative Commons License