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 <[EMAIL PROTECTED]> Date: Fri, 03 Feb 2006 22:45:23 To:[email protected] 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 <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> >>To: "Hernan Cunico" <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> >>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 >> >> >> >> > >
