Changes between Initial Version and Version 1 of Ticket #13965


Ignore:
Timestamp:
Feb 27, 2021, 10:48:39 PM (3 years ago)
Author:
clemens
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #13965 – Description

    initial v1  
    2525}}}
    2626
    27 = Genshi
    28 As far as I know, the plugin is still based on Genshi (see #13283).
    29 However, experiments indicate that this may not be the cause of the problem.
    30 
    3127= SQL
    3228
    33 For me it looks like the performance bottleneck is the SQL query not the Genshi template processing.
     29First I suspected that SQL database query might be the performance bottleneck.
    3430
    35 I made an experiment to limit the number of change-log to 10 (instead 150). As expected I got only 10 change-logs in the output. Unfortunately this did not change the extreme long wait time (still >30 seconds).
     31However, it seems SQL is not the problem (as far as I could find).
     32
     33=== SQL experiment 1
     34
     35I made an experiment to limit the number of change-log to 10. As expected I got only 10 change-logs in the output. Unfortunately this did not change the extreme long wait time (still >30 seconds for 150 changesets).
    3636
    3737The SQL query is made in function `_get_ticket_revisions` in
    … …  
    4848    LIMIT 10
    4949}}}
    50 Note the `LIMIT 10` in the last SQL line which I inserted in my experiment. The total wait time is not influenced by this "LIMIT 10".  I am neither a database nor TRAC expert. But this SQL query looks rather simple. I cannot imagine that this takes 30 seconds. The `ticket_revision` table is short and has only 1000 rows on my repo.
     50Note the `LIMIT 10` in the last SQL line which I inserted in my experiment. The total wait time is not influenced by this "LIMIT 10". 
    5151
    52 Please help, my TracTicketChangelogPlugin is still very slow. It takes over 30 seconds for some tickets. If I cannot find a solution I must disable this wonderful plugin.
    53  
     52=== SQL experiment 2
     53
     54Next I simply removed the SQL query from code.
     55Instead I simply assigned fixed values to the variables.
     56
     57Result: It did not change the loading time.
     58
     59= Genshi
     60
     61As far as I know, the plugin is still based on Genshi (see #13283).
     62
     63Can this be a performance problem?
     64
     65In my log I can see the following warning:
     66{{{
     67 Trac[chrome] WARNING: Component TicketLogModule relies on deprecated Genshi stream filtering
     68}}}
     69
     70I experimented with the Python code and could find out that the following line 150 from `filter_stream` function may be responsible:
     71source:/tracticketchangelogplugin/1.2/ticketlog/web_ui.py#L150
     72{{{#!python
     73stream |= Transformer('//div[@id="ticket"]').after(template)
     74}}}
     75
     76If I disable this line, then as expected the change-log will not appear in the HTML output, but the loading time will be quick.
     77
     78= Tickets
     79
     80What is confusing is that the loading time problem seems not proportional with the number of change-sets. I have tickets with 300 related SVN change-sets which load faster than other tickets with 150 related SVN change-sets. Also note that our ticket descriptions are often very
     81
     82I could not find the pattern, but it seems to be a combination of:
     83 - number of related SVN change-sets
     84 - number of ticket changes (my users often change ticket description)
     85 - length or complexity of ticket description (my users love long description texts with many tables and pictures)
     86
     87Just to make this sure, __all__ tickets (even the longest ones) load quickly as soon as I disable the TracTicketChangelogPlugin.