On Apr 4, 2008, at 2:04 PM, Michael S. Fischer wrote: > On Fri, Apr 4, 2008 at 11:05 AM, Ricardo Newbery <[EMAIL PROTECTED] > > wrote: > >> Again, "static" content isn't only the stuff that is served from >> filesystems in the classic static web server scenario. There are >> plenty of >> "dynamic" applications that process content from database -- >> applying skins >> and compositing multiple elements into a single page while >> filtering every >> element or otherwise applying special processing based on a user's >> access >> privileges. An example of this is a dynamic content management >> system like >> Plone or Drupal. In many cases, these "dynamic" responses are fairly >> "static" for some period of time but there is still a definite >> performance >> hit, especially under load. > > If that's truly the case, then your CMS should be caching the output > locally.
Should be? Why? If you can provide this capability via a separate process like Varnish, then why "should" your CMS do this instead? Am I missing some moral dimension to this issue? ;-) In any case, both of these examples, Plone and Drupal, can indeed cache the output "locally" but that is still not as fast as placing a dedicated cache server in front. It's almost always faster to have a dedicated single-purpose process do something instead of cranking up the hefty machinery for requests that can be adequately served by the lighter process. Ric _______________________________________________ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
