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!"
--- Begin Message ---
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
--- End Message ---
