|Version 8 (modified by 13 years ago) ( diff ),|
Trac and Performance
In the past, Trac garnered a reputation of being a fast web application. This was mainly due to its use of the ClearSilver template engine. Starting with version 0.11, Trac migrated to Genshi, another template engine, much more flexible and powerful in many ways, but also much slower and memory hungry. As the memory usage seems now mostly OK (#6614), there are still many concerns over the performance.
However Genshi is not the only reason for the perceived slowdown, there are several other factors which have to be taken into account when analyzing performance:
- the increased usage of plugins, each of them can add to the load in subtle ways
- the new security model of TracFineGrainedPermissions
- the conditions in which Trac is run (web front-end)
- the specific configuration settings of Trac used
- various bugs that might be triggered by any of the above!
In this page we'll try to collect all the various pieces of information related to performance, in order to compile a "checklist" that can be followed when trying to troubleshoot a performance problem, or simply when one wants to get a better performance out of his Trac installation.
Check your installation
If Trac is not installed correctly, performance will suffer.
The most obvious wrong thing to do here is installing Trac as a CGI script. Even for testing, there are better alternatives (tracd).
The second main installation mistake relative to performance would be to serve static resources through Trac. For best performance, they're better served by a web server, see TracCgi#MappingStaticResources
(Note: we should probably move the mapping static resources section to another page, e.g. TracModWSGI)
Other points worth checking:
- if using mod_python, only use latest version (3.3.1); prefer mod_wsgi (≥ 2.4) (daemon mode)
- running Trac under QEMU is slow (ticket:7490#comment:42)
- in Apache, there's a possible issue when using mod_deflate (#8534, googlegroups:trac-users:ab070d251f5a0d11); on the other hand, some people have good results with mod_deflate and advise using it (TracDev/Performance/0.11.5)
Check your configuration
Several settings enhance Trac in one way or the other, but have a performance cost, which in some case can be huge.
default_daysbackset to a high value might induce quite some load, depending on the activity. Pick an appropriate value for your site.
- the default
max_daysbackcan be inappropriate (e.g. allowing 90 days for a site with lots of activity might be way too much). Don't hesitate to reduce it, especially now that we have paging
- any setting value than
changeset_show_files = 0can be really expensive, depending on the quantity of changesets to process
Check your trac.log
- look for INFO messages: Reloading environment due to configuration change
if you find lots of such lines, or even worse, if they appear systematically, then chances are that you're using a plugin which does systematic updates to the configuration file (trac.ini), and this will in turn trigger a full environment reload at the next request. That can slow down the performance a lot, to the level of TracCgi. See ticket:7490#comment:102 and follow-up.
- look for INFO messages like repos rev  != cached rev  (other revision numbers for you, of course)
if you find such lines and the
cached revvalue doesn't change, this corresponds to a repository resync failure which results in a resync attempt for every request (see ticket:7490#comment:36); often due to the "prohibited" MySQL/MyISAM combination (#8067)
- there was a bug up to 0.11.4 which could cause 100% cpu usage once in a while on some platforms (#7785, thought to be fixed in 0.11.5, but re-opened since)
- some plugins seem to have a high impact on the performance (read TracDev/Performance/0.11.5)
- a mis-configured or simply slow mail server make Trac appear very slow (#3220 and numerous others)
See also: TracDev/Performance