RE: [BCD396XT] Re: New Wiki
- View SourceAnother thing that may help is by using persistent perl, where it all
resides in memory.
From: BCD396XT@yahoogroups.com [mailto:BCD396XT@yahoogroups.com] On Behalf
Sent: Thursday, December 25, 2008 1:54 PM
Subject: [BCD396XT] Re: New Wiki
--- In BCD396XT@yahoogroups.com, "pmanu44" <pmanu44@...> wrote:
> --- In BCD396XT@yahoogroups.com, "Peter Laws" <plaws0@> wrote:
> There is a server-side caching add-on that I'll try on Monday. The
> side to it seems to be that there could be some latency between
> changes and the changed page being served up. The first (ever)
> someone to a page would be as slow as now, but after that the fast
> cached version would be used (and should serve up in <.1 seconds).
Twiki is written in Perl, and executed via CGI (slow). This type of
software implementation really needs a cache in order to get decent
performance out of it. Caching solutions include mod_perl, fastcgi,
I'm not sure how any of these caching mechanisms would cause a delay
in content availability. It is the code/byte/database objects that
are cached, not content (with perhaps some exceptions).
It seems like mod_perl could be the best fit, with some possible
caveats. It appears the attitude is "try it, if it works - great."
Fastcgi appears to be the best technical fit (as it often is in these
cases), yet you'll have to get busy with a text editor to implement
it correctly. Not hard, but for sure in bad form by the twiki project
folks. It really would not have been hard to properly support this.
Please DO NOT implement a content cache (ie, PublicCacheAddOn,
VarCachePlugin, etc). This is a 'first byte returned' issue, not a
content issue. If you stop the fork->parse->compile->execute process
on every request, you'll be much happier.
Yahoo! Groups Links