[[PageOutline(2-5,Contents,pullout)]] = Trac and Performance This page collects Trac performance issues, solutions and troubleshooting. When dealing with performance degradation on a Trac installation there are some potential causes to consider: - a large number of plugins may add to the load in subtle ways - the security model of TracFineGrainedPermissions - the conditions in which Trac is run (web front-end) - the specific configuration settings of Trac - various bugs that might be triggered by any of the above == Check your installation #Installation If Trac is not installed correctly, performance will suffer. The most obvious mistake is installing Trac as a CGI script. Even for testing, there are better alternatives, see [TracStandalone tracd]. The second main installation mistake relative to performance would be to serve static resources through Trac. For best performance, Trac pages should be served by a web server, see TracInstall#MappingStaticResources. {{{#!comment we should probably move the ''mapping static resources'' section to another page, e.g. [wiki:TracModWSGI] }}} Other points worth checking: - When using '''mod_python''', use at least version 3.3.1; prefer '''mod_wsgi''' (at least version 2.4), ie daemon mode. - Running Trac under the '''QEMU virtualizer''' is slow (ticket:7490#comment:42). - In Apache there is a possible issue when using '''mod_deflate''' (#8534, googlegroups:trac-users:ab070d251f5a0d11); however, some people have good results with mod_deflate and advise using it (["TracDev/Performance/0.11.5#HowItimed"]). - Some third party packages, such as '''Pygments''', could also be responsible for heavy CPU loads; specifically, Pygments 1.0's '''scala mode''' ([https://bitbucket.org/birkenfeld/pygments-main/issue/392/scala-lexer-hangs-forever #392]). - Ensure an image has been configured as the Trac logo in the top left. The default install from Ubuntu 10.04 for example does not include a default logo and this makes pages slow to load. == Check your configuration #Configuration Several settings enhance Trac in one way or the other, but have a performance cost, which in some cases can be large. Other settings can help improve (perceived) performance. === `[timeline]` #timeline-section - `default_daysback` set to a high value might introduce quite some load, depending on the activity. Pick an appropriate value for your site. - the default `max_daysback` can be inappropriate, eg allowing 90 days for a site with lots of activity might be too much. Don't hesitate to reduce it, especially now that Trac supports paging - any setting other than `changeset_show_files = 0` can be expensive, depending on the quantity of changesets to process === `[ticket]` #ticket-section - use of `restrict_owner = true` can be slow on some installations (see #4245, #8034, #8212). === `[trac]` #trac-section - `use_chunked_encoding` - `use_xsendfile` and `xsendfile_header` - `repository_sync_per_request` (Trac < 1.2) === `[git]` #git-section - Use of `trac_user_rlookup` can reduce performance if there are many users and the `cached_repository` option is disabled. - `persistent_cache` and `cached_repository` === `[gitweb-repositories]` #gitweb-repositories-section - `sync_per_request` option. === `[repositories]` - `.sync_per_request` option (Trac >= 1.2). == Check your [TracLogging trac.log] #Log Search for the following: - INFO messages: '''Reloading environment due to configuration change''' [[br]] 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 [TracIni 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. - INFO messages: '''rev ![321] != cached rev ![123]''' (other revision numbers for you, of course) [[br]] If you find such lines ''and the `cached rev` value 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 as a result of the "prohibited" MySQL/MyISAM combination (#8067). - WARNING message: '''Slow mail submission''' [[br]] A mis-configured or simply slow mail server make Trac appear very slow (#3220). - Excessive permission checks. - Enable `[trac] debug_sql` and check DEBUG messages for excessive SQL queries. == Templates - After the adoption of the [genshi:Genshi] template engine in [/milestone/0.11 Trac 0.11] in 2008, some associated performance issues were solved (#6614). - In Trac 1.3 the Jinja template engine was adopted and performance is improved over Genshi (#12639). - Many plugins still use Genshi templates, which are supported for compatibility until Trac 1.5.1. - Plugins that use the `ITemplateStreamFilter` interface prevent the performance improvements gained by using Jinja. == Database - Use PostgreSQL or MySQL for many users to avoid lock contention. - Otherwise consider using SQLite with connection string `sqlite:db/trac.db?journal_mode=wal&synchronous=off` if tolerable. (#11967) == Unsorted - 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, see ["TracDev/Performance/0.11.5#customizationsandplugins"]. - Trac's [http://trac.edgewall.org/query?status=!closed&keywords=~performance performance issues]. == Profiling a Trac request I've written a blog post on how I do basic profiling for Trac. It includes a simple script that I use to check single requests. [https://www.coderesort.com/u/simon/blog/2011/09/06/trac_profiling Read it @ my blog]. -- osimons ---- See also: TracDev/Performance [[TitleIndex(TracPerformance/)]]