This question about Configuration: Answered but needs rewriting
Foswiki Cache optimisation
--
NeilMcKett - 09 Aug 2012
Hi,
I've been reading through various support topics to try and understand the best way to configure the Foswiki 1.1.5 page cache. It seems that at the moment only BDB is supported while mysql is in development. Could someone let me know the best way to configure a server's cache for a site which hosts about 60 000 pages? I have tried various options - BDB/ DB_File;
MemCaheLRU ; cache size etc etc - but after a large number of pages hits the cache slows down considerably for both viewing and saves.
We use speedy_cgi for our server as this works really well for Foswiki 1.0.9.
Thanks.
Best Wishes
Neil
Hi Neil, that's a known issue. Disable the page cache for now. There's a complete rewrite of it part of one of the next foswikis being released. See
Tasks.Item11549.
--
MichaelDaum - 09 Aug 2012
Thanks for answering this. At the moment Foswiki 1.1.5 without the Cache on is too slow. Could you let me know whether the cache issue will be fixed in 1.1.6 and whether performance with cache off could be improved ( currently much slower than 1.0.9 ).
Thanks
--
NeilMcKett - 10 Aug 2012
Best Wishes
Neil
Are there plans to fix this in 1.1.7 ( looks like nothing has changed in 1.1.6 )?
Thanks
--
NeilMcKett - 06 Dec 2012
Unfortunately the page cache fixes are more extensive than should be made in a patch release. The Cache was completely redesigned / rewritten for Foswiki 1.2, and has been active on
http://trunk.foswiki.org/Support/Question1151 for testing. It is showing good results there and will be released in Foswiki 1.2.0, which is expected to be the next release of Foswiki.
We will be shortly making available a small patch for Foswiki 1.1.5 and 1.1.6 which addresses some slowness in the Store, reported in
Tasks.Item11983. Keep an eye out for
PatchItem11983Contrib. The fix for 1.1.5 and 1.1.6 however does have some risk if your site has topic that are modified external to foswiki. The fix for 1.2 is much more extensive.
--
GeorgeClark - 06 Dec 2012