Loading ...
Sorry, an error occurred while loading the content.

RE: [BCD396XT] Re: New Wiki

Expand Messages
  • Joe Polcari
    Another thing that may help is by using persistent perl, where it all resides in memory. ... From: BCD396XT@yahoogroups.com [mailto:BCD396XT@yahoogroups.com]
    Message 1 of 7 , Dec 25, 2008
      Another thing that may help is by using persistent perl, where it all
      resides in memory.

      -----Original Message-----
      From: BCD396XT@yahoogroups.com [mailto:BCD396XT@yahoogroups.com] On Behalf
      Of Ryan
      Sent: Thursday, December 25, 2008 1:54 PM
      To: BCD396XT@yahoogroups.com
      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)
      visit by
      > 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,
      SpeedyCGI, etc.

      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
    Your message has been successfully submitted and would be delivered to recipients shortly.