id summary reporter owner description type status priority milestone component version severity resolution keywords cc branch changelog apichanges internalchanges 9938 Improve on static resources Carsten Klein "I know there are multiple ways of externally optimizing servicing static resources from a trac environment. However, for must users these are way off their limits, so here is a different approach that is directly built into trac. By default, the chrome component is the instance where all template providers will be evaluated for servicing static resources for a given prefix and filename /aka path. As of now, requests for these files will be processed by the chrome component's request handler, which then will call req.send_file for sending the file. Since this requires the whole bunch of the default request dispatcher component, along with multiple other instances of components being either instantiated or referenced, overall servicing latency is rather high, especially for resources that lead to a 404 or 304 response. My proposition is now to introduce a `StaticResourceCache` component at the web.main level, which will then be used by both the chrome component for registering resources and the main _dispatch_request routine. The cache will be filled lazily, so for each resource currently not in the cache, the default request dispatcher will call chrome to process the request normally. As soon as the resource is in the cache, the _dispatch_request function will intercept the call and directly handle the static resource request. In my local environment, this has lowered response times by about 100...500ms. As an example, for a given page I did multiple reloads and viewing the results in firebug's network monitor. Without the optimizations, response times for static resources vary from 13ms to >200ms. With the optimizations, response times for static resource become much more reproducible, varying also from 13ms to >200ms. The peaks, however, are now less frequent and overall response times are well below the 60ms mark. A nice side effect is that, the overall time for fetching a simple page has dropped from >560ms .. 1,2s (without optimizations) to 420ms..1,2s (with the optimizations). Again, here the peaks are less perceptible, especially when reloading the same page during edit/save/preview cycles. You can find the source for that patch under http://github.com/axnsoftware/trac-bugs-n-features. I will name you the branch as soon as I have the ticket id. " enhancement new normal next-major-releases web frontend 0.13dev normal performance