geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <ammul...@alumni.princeton.edu>
Subject Re: Why Confluence cannot not be used as a wiki, and how it might be fixed
Date Fri, 03 Feb 2006 21:36:44 GMT
I'm not sure how to interpret this; are Ken/Noel suggesting that we
should stop using Confluence for the time being, or just that there
are more obstacles to get it fully implemented than were initially
expected?

Thanks,
    Aaron

On 2/3/06, Rodent of Unusual Size <Ken.Coar@golux.com> wrote:
> Forwarding to the dev@ list with permission.  This
> is where it belongs.
> --
> #ken    P-)}
>
> Ken Coar, Sanagendamgagwedweinini  http://Ken.Coar.Org/
> Author, developer, opinionist      http://Apache-Server.Com/
>
> "Millennium hand and shrimp!"
>
>
>
> ---------- Forwarded message ----------
> From: "Noel J. Bergman" <noel@devtech.com>
> To: "Hernan Cunico" <hcunico@gmail.com>, <infrastructure@apache.org>
> Date: Fri, 3 Feb 2006 10:08:19 -0500
> Subject: Why Confluence cannot not be used as a wiki, and how it might be fixed
> To quote Atlassian: "Confluence will likely die if slashdotted, so shouldn't
> be used as a *primary* project website if slashdotting is likely."  Read
> "slashdotting" as heavy load, and we experience sufficient load on the Wiki
> to make caching mandatory.
>
> See:
> http://confluence.atlassian.com/display/DOC/Running+Confluence+Behind+a+Cach
> ing+Proxy+Server
>
> The comment:
>
>  "The main problem with the reverse-proxy solution is that every
>   Confluence page is built dynamically for whichever user is
>   currently accessing it."
>
> is a typical indicator of a common problem in many dynamic content systems,
> which all too often neglect the fact that 99.999+% of all traffic is going
> to be relatively static and anonymous.  Dynamic does not mean ephemeral, and
> that distinction is missed all too often.
>
> The facts are that most Wiki access is anonymous, and Wiki content is almost
> entirely static and should be cachable.  Confluence intentionally breaks
> caches, and that behavior needs to be fixed.  There are a number of possible
> solutions.
>
> One way, and just a simple one, since there are others, would be for
> anonymous and authenticated access could have different URLs, e.g.,
> mydomain.tld/confluence/anon/ for the public, and
> mydomain.tld/confluence/auth/ for authenticated users.  That would permit
> the vast majority of accesses to be cached.  "WAIT", you say, "What about
> when someone edits the page under the /auth/ path?  Won't that cause a
> problem for viewers in the /anon/ path?"  Not if the URLs are properly
> designed, and the system is supporting Conditional Get.  The /anon/ path
> should be handling Conditional Get based upon the timestamp of the page
> resource.  So most GET requests will simply return 304, unless the page has
> been changed, in which case the updated resource can be returned and cached.
>
> So these are technical issues (Joshua Slive outlined other, related, ones),
> and the ball has been in Atlassian's court to provide some resolution.
>
>         --- Noel
>
>
>
>

Mime
View raw message