Thanks for the link info. I literally just set up Varnish for the first time on my web host, so I am no pro. However, varnish uses a c like scripting language that can run regexps on the incoming urls and apply rules to them. What this means is that we can (as a starting point) choose caching times for each of those high traffic urls in the varnish script without touching trac. In the script, we match the front page (with a regexp) and add a max-cache time to 86400, cache it, etc. See http://www.catalystframework.org/calendar/2008/14 for a great varnish tutorial By doing that for each of the urls you listed (bar the timeline, which should be cached for 1 hour or perhaps 30 minutes instead) we will seriously lighten the load on the database and the webserver, even if varnish runs on the same machine (as a start). Every other url (which doesn't have caching set) we could just cache for 30 minutes (perhaps even a day), but only for anon users (no cookies set in browser) -Tom

...

On 10:41 pm, leyssw@ihug.co.nz wrote:

...

Isn't the simplest option to place a decent reverse proxy between the webserver and our clients?

Possibly so! I gave this a half-hearted attempted a few weeks ago but quickly gave up. If someone who is familiar with configuring such a proxy would like to help out, perhaps we can get something useful up and running.

Actually, I just looked at Varnish again and remembered that because of the way trac sessions work, it's really hard to figure out what may and may not be correctly cached. I don't know how to resolve this without serious changes to trac itself.

Jean-Paul

------------------------------

_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

End of Twisted-Python Digest, Vol 68, Issue 13 **********************************************