Re: Why Confluence cannot not be used as a wiki, and how it mightbe fixed

[Jason Dillon <ja...@planet57.com>]

I will belive it when I see it. 

In the mean time, changing the layout not to render user specific mumbo jumbo by default should take care of 90% of the problem. 

--jason


-----Original Message-----
From: Hernan Cunico <hc...@gmail.com>
Date: Fri, 03 Feb 2006 22:45:23 
To:dev@geronimo.apache.org
Subject: Re: Why Confluence cannot not be used as a wiki, and how it might
 be fixed

In terms of performance, Atlassian team is working on a "Confluence Massive" that will run in a 
cluster. That should not only address performance but also high availability.
Does anybody have more details on this?

Cheers!
Hernan

Aaron Mulder wrote:
> 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 <Ke...@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" <no...@devtech.com>
>>To: "Hernan Cunico" <hc...@gmail.com>, <in...@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
>>
>>
>>
>>
> 
>