[[PageOutline(2-5,Contents,pullout)]]

= Trac and Performance

This page collects Trac performance issues, solutions and troubleshooting. It focuses on settings in Trac only, as opposed to settings related to your database or web server.

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
 - 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, such as [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]`
 - `<name>.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 many 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'', then 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 makes Trac appear very slow (#3220).
 - Excessive permission checks.
 - Enable `[trac] debug_sql` and check DEBUG messages for excessive SQL queries.

== Templates

In Trac 1.3 the Jinja template engine was adopted and performance has 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 eliminate the performance improvements gained by Jinja.

== Database

 - Use PostgreSQL or MySQL if your environment has many users; this is 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 Trac 0.11.4 which could cause 100% CPU usage once in a while on some platforms. See #7785, which was thought to be fixed in 0.11.5, but re-opened since.
 - Some plugins seem to degrade performance, see ["TracDev/Performance/0.11.5#customizationsandplugins"]. 
 - The more plugins, the higher the potentiality for performance degradation in unpredictable ways: install, test and use plugins in a staggered fashion to better understand since when and how performance has degraded.
 - Trac's [query:status=!closed&keywords=~performance tickets regarding performance].

----
See also: TracDev/Performance
[[TitleIndex(TracPerformance/)]]