Improve on static resources

[Carsten Klein <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.

[Carsten Klein <carsten.klein@…>]

The branch is trac-issue-9938.

[Carsten Klein <carsten.klein@…>]

Oops, I forgot to escape the StaticResourceCache. Could you, please, edit the description for me? TIA

[Christian Boos]

Though one should really just bypass Trac for the static resources and use a real web server for this, the idea looks interesting:

• would be useful for tracd-only setups
• will help until we implement the chrome_location extension to htdocs_location (#9683)

Care to prepare a minimal patch, with just that StaticResourceCache?

[carsten.klein@…]

I will try to make this available on sunday and clean up the sources and the repository by rebasing a bit.

[carsten.klein@…]

Consolidated Patch

[carsten.klein@…]

git is a fine tool but the learning curve is steep - here is your patch :D