I've copied the Trac-dev list on this since it's a development issue. Please continue the discussion on that list.
-- Matt Good On Feb 9, 1:31 am, "Michael Renzmann" <[EMAIL PROTECTED]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi all. > > As some of you might already know, I'm running the Trac installation on > madwifi.org. We're happy with Trac, it's a great tool that we don't want > to miss anymore. But there is one issue that we would like to see > addressed: performance. > > Background > ========== > Our handicap is that the server that currently hosts madwifi.org > > a) hosts several sites > b) has a slow CPU (P3-800) > c) runs on Apache 2.0 with mpm_prefork and can not switch to, for example, > mpm_worker - another site depends on mod_php, and mod_php doesn't like > mpm_worker > > The site will move to a dedicated server soon, which should mitigate the > performance issues we experience (as described below) a bit - no more > mod_php, so mpm_worker will finally be possible. However, the available > CPU power won't be much better: P3-850 instead of P3-800. Changing to a > more powerful server is not (yet) possible due to a lack of money. We have > to take what we get. > > The problem > =========== > For every request to a Trac-driven site, Trac has to "render" the content > first. In case of a wiki page as an example that would be something like: > get the markup for the page from the database and process it, getting the > HTML tag soup as result that then is delivered to the requesting client. > > The more complex the "source" of a requested page is, the more CPU time is > consumed by Trac to render it. An example for such a case is our > compatibility list athttp://madwifi.org/wiki/Compatibility- if that page > gets hit by several clients in parallel, the server is getting really > slow. > > (Yes, I'm aware that reducing the complexity of the mentioned page will be > a way to relieve the pain a bit, and actually that is work in progress - > but that's not the point here :)). > > On the other hand, the majority of the frequently requested pages seem to > be rarely changed. So the question for me is: why should Trac compute the > same page over and over again when most of the time the result will be the > same as for the last request? > > The suggested solution: caching > =============================== > In theory, it shouldn't be hard to store the result of rendering a page > and serve subsequent requests for that page out of the cache. Adding > support for conditional HTTP requests (If-None-Match and If-Modified-Since > headers) at the same time could help to reduce the used bandwidth. > > The easiest way to handle cache updates would be to remove cached results > when the corresponding page gets modified. Next time that page is > requested, it is rendered (including the changes) and the result gets > stored in the cache again. > > Caching might become a problem for really dynamic sections of a Trac site, > such as the reports. But it should relieve the server for mostly-static > parts, which - at least on madwifi.org - make the majority of the site. > > Another issue that should be considered is that pages could look different > for different users - depending on their permissions. That could be solved > in various ways, for example: > * no caching for pages requested by a non-anonymous user > * implement a per-user cache (needs to be wiped when permissions for a > user are changed) > * take the actual permissions into account when storing and retrieving > pages to/from the cache > > Comments? > ========= > I'd be interested in comments on the sketched idea. Even more, it would be > great if there was someone who would be interested in helping to implement > it :) > > Bye, Mike > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.1 (GNU/Linux) > > iEYEARECAAYFAkXMFVMACgkQa3V7dXg8JKv1hACg2bJ3iq0UK7/two8zmxRfVlyV > XXwAn29f2PkXb51iTAQNkalhGhLI3YFG > =0K+W > -----END PGP SIGNATURE----- --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~----------~----~----~----~------~----~------~--~---
