Edgewall Software
Modify

Opened 13 years ago

Last modified 13 years ago

#9938 new enhancement

Improve on static resources

Reported by: Carsten Klein <carsten.klein@…> Owned by:
Priority: normal Milestone: next-major-releases
Component: web frontend Version: 0.13dev
Severity: normal Keywords: performance
Cc: Branch:
Release Notes:
API Changes:
Internal Changes:

Description (last modified by Christian Boos)

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.

Attachments (1)

patch-9938 (14.8 KB ) - added by carsten.klein@… 13 years ago.
Consolidated Patch

Download all attachments as: .zip

Change History (7)

comment:1 by Carsten Klein <carsten.klein@…>, 13 years ago

The branch is trac-issue-9938.

comment:2 by Carsten Klein <carsten.klein@…>, 13 years ago

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

comment:3 by Remy Blank, 13 years ago

Description: modified (diff)

comment:4 by Christian Boos, 13 years ago

Component: generalweb frontend
Description: modified (diff)
Keywords: performance added
Milestone: next-major-0.1X

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?

comment:5 by carsten.klein@…, 13 years ago

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

by carsten.klein@…, 13 years ago

Attachment: patch-9938 added

Consolidated Patch

comment:6 by carsten.klein@…, 13 years ago

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

Modify Ticket

Change Properties
Set your email in Preferences
Action
as new The ticket will remain with no owner.
The ticket will be disowned.
as The resolution will be set. Next status will be 'closed'.
The owner will be changed from (none) to anonymous. Next status will be 'assigned'.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.