Redmine 0.9.2 front-end performance
Added by Alexander Balabanov over 14 years ago
Hi.
We're using Redmine as an everyday day tool and I'm looking for options to increase its front-end performance. We're now on 9.2.dev branch and there's a strange thing inside. All css and js links are spiced up with some hash or smth:
<link href="/work/themes/custom/stylesheets/application.css?1266121219" media="all" rel="stylesheet" type="text/css" />
<script src="/work/javascripts/prototype.js?1265564198" type="text/javascript"></script>
<script src="/work/javascripts/effects.js?1265564198" type="text/javascript"></script>
<script src="/work/javascripts/dragdrop.js?1265564198" type="text/javascript"></script>
<script src="/work/javascripts/controls.js?1265564198" type="text/javascript"></script>
<script src="/work/javascripts/application.js?1265564198" type="text/javascript"></script>
<link href="/work/stylesheets/jstoolbar.css?1265564198" media="screen" rel="stylesheet" type="text/css" />
Any suggestions on how to remove/avoid them?
Replies (8)
RE: Redmine 0.9.2 front-end performance
-
Added by Felix Schäfer over 14 years ago
AFAIK these hashes are timestamps added by rails that are added to enable better client-side caching.
RE: Redmine 0.9.2 front-end performance
-
Added by Alexander Balabanov over 14 years ago
I always thought that such URL modifiers prevent correct caching. There are Cache-Control
and etag
to tell browser how to handle caching.
So this is Rails feature, not a Redmine one?
RE: Redmine 0.9.2 front-end performance
-
Added by Felix Schäfer over 14 years ago
Not sure why the other schemes are not used that extensively (etags get used), but appending a timestamp avoids the client hitting the server to ask if the etag it has is still valid, because if the file is updated, the timestamp changes and the client will immediately notice the change rather than believing the locally cached version is still uptodate.
Anyway, it's a rails thing, and it won't make your clients faster to meddle with it. I don't know what signs of "slowness" you experience, but I think there are other bolts and nuts to play with to make it better :-)
RE: Redmine 0.9.2 front-end performance
-
Added by Felix Schäfer over 14 years ago
Here is more info on that http://api.rubyonrails.org/classes/ActionView/Helpers/AssetTagHelper.html . Google for "rails asset caching" for more info.
RE: Redmine 0.9.2 front-end performance
-
Added by Alexander Balabanov over 14 years ago
Felix Schäfer wrote:
Here is more info on that http://api.rubyonrails.org/classes/ActionView/Helpers/AssetTagHelper.html . Google for "rails asset caching" for more info.
Thanks a lot, I'll dig into it.
My aim is to minify and merge all CCS and JS files, deliver them both gzipped and correctly cache-marked. I'm sure it will give a nice boost for everyday use.
RE: Redmine 0.9.2 front-end performance
-
Added by Felix Schäfer over 14 years ago
Well, if you use apache, you can just deflate .js and .css, and set their expiration date far in the future, the timestamps will make sure you clients fetch the new ones as needed. Anyway, I find it quite fast as it is, at least on our installations (see http://orga.fachschaften.org for and example).
RE: Redmine 0.9.2 front-end performance
-
Added by Alexander Balabanov over 14 years ago
Your copy is indeed really fast. What's your backend, if it's not a secret?
RE: Redmine 0.9.2 front-end performance
-
Added by Felix Schäfer over 14 years ago
No secret at all :-) Here's the redmine part:
xxx orga.fachschaften.org # RAILS_ENV=production ./script/about About your application's environment Ruby version 1.8.7 (x86_64-linux) RubyGems version 1.3.5 Rack version 1.0 Rails version 2.3.5 Active Record version 2.3.5 Active Resource version 2.3.5 Action Mailer version 2.3.5 Active Support version 2.3.5 Application root /var/www/orga.fachschaften.org Environment production Database adapter mysql Database schema version 20100211155700 About your Redmine plugins Issue Due Date 0.1.0
The mysql has somewhat more memory allocated than the default config (I think the default config assumes mysql has 32MB RAM or something). The whole shebang is served through passenger on apache, here the interesting parts of the apache config:
xxx modules.d # egrep -v '(^#|^$)' 30_mod_passenger.conf <IfDefine PASSENGER> LoadModule passenger_module modules/mod_passenger.so PassengerRoot /usr PassengerLogLevel 1 PassengerRuby /usr/bin/ruby18 RailsAutoDetect On PassengerMaxPoolSize 20 PassengerPoolIdleTime 0 PassengerMaxInstancesPerApp 0 PassengerUserSwitching On PassengerDefaultUser apache PassengerHighPerformance on RailsSpawnMethod smart RailsFrameworkSpawnerIdleTime 0 RailsAppSpawnerIdleTime 0 </IfDefine>
The interesting part here are the last 4 config items that streamline passenger a little bit (all passenger processes share one rails in memory instead of spawning one each, and the application is kept in memory to allow quicker spawning of new processes, see the passenger docs for more info). I also have deflate activated for the static parts:
AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css application/x-javascript
The only thing missing that could be added is the expiry headers "far in the future" as described in the Using asset timestamps in the above mentioned API page (which I'll add just now ;-) ), but it really just makes the clients cache the static files longer.
Anyway, you also wanted to bundle the js and css files, that will give you as good as no measurable performance increase, because http 1.1 reuses the same one or two connections to download all files, so you don't have any extra overhead caused by a big number of http connections, so I would recommend against it, especially because you will then have to maintain the changes afterward. You will yield better performance by making your rails stack faster, google for rails optimizations or stuff like that to find out more about that.