Changes between Version 17 and Version 18 of TracPerformance

Timestamp:

Jan 9, 2016, 9:22:30 PM (8 years ago)

Author:

figaro

Comment:

Cosmetic changes

TracPerformance

@@ +1 @@
+[[PageOutline(2-5,Contents,pullout)]]
+
 = Trac and Performance
 
-With Trac 0.11, the ClearSilver template engine was replaced with the Genshi template engine, but with its increased flexibility, Trac also became slower and memory hungry. As memory usage seems now mostly OK (#6614), there are still many concerns over Trac's performance.
+After the adoption of the [genshi:Genshi] template engine in [/milestone/0.11 Trac 0.11] in 2008, some associated performance issues were also solved (#6614). There are however, still occasional concerns over Trac's performance.
 
-However, apart from Genshi, there are several other factors to be taken into account when analyzing performance:
- - the increased usage of plugins, each of them can add to the load in subtle ways
+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 new 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!
+ - various bugs that might be triggered by any of the above
 
 This page collects Trac performance issues, solutions and troubleshooting.
@@ -17 +19 @@
 
 The second main installation mistake relative to performance would be to serve static resources through Trac.
-For best performance, Trac pages are better served by a web server, see TracCgi#MappingStaticResources.
- ''(Note: we should probably move the ''mapping static resources'' section to another page, e.g. [wiki:TracModWSGI])''
+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:
- - if using mod_python, only use latest version (3.3.1); prefer mod_wsgi (>= 2.4), ie daemon mode
- - running Trac under the QEMU virtualizer 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#HowItimed"])
- - some 3^rd^ 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.
+ - 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
@@ -32 +36 @@
 
 === `[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 we have paging
- - any setting other than `changeset_show_files = 0` can be really expensive, 
-   depending on the quantity of changesets to process
+   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 ...)
+
+ - use of `restrict_owner = true` can be slow on some installations (see #4245, #8034, #8212).
 
 == Check your [TracLogging trac.log] #Log
@@ -50 +55 @@
    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 and numerous others).
+   A mis-configured or simply slow mail server make Trac appear very slow (#3220).
 
 == Unsorted
@@ -56 +61 @@
  - 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