Closed kofalt closed 14 years ago
Specifically, the "Commits by author" section can load up to a full minute after the rest of the page has loaded.
Caching is one of the next things on the list.
Just out of curiosity, how many revisions do you have?
Only 300, which I thought was odd since you mentioned you've used this on a repository with thousands of commits. The server this my Trac instance is running on is older, but I've never had performance problems with anything else I've tried.
In case it matters, the hardware is an Intel Pentium III-S @ 1113 Mhz with 3GB of RAM. I would hope that isn't important though :)
Odd, I've used this with a repository of over 100,000 commits. When I focus on caching and performance soon I will do some profiling to see where the time might be being spent.
I found a performance regression on Trac 0.12 which was causing really awful performance. As part of the database schema changes, they implemented "multi-repository" support which means the revision is no longer unique, now it is the (repository, revision) pair. I updated the SQL I'm using and made a few other changes... now it should be a LOT faster.
Want to try again?
affirmative - everything is much faster on trac 0.12 now.
thumbs up!
mrjb7: I'll take a look at it this weekend. I am running Trac 0.11 - will I have problems upgrading to the latest?
Should work just fine - I've tested it in several configurations.
Tested & approved! :)
Excellent!
Code view could be faster (discussed in #2).
Additionally, it may be a smart idea to cache these results/graphs and only regenerate them if there's new data. Ideally:
1) If there's no cached results, generate manually 2) Check to see if there's a new revision / ticket change / wiki edit (as appropriate) 3) If there's no new changes, return the cached results 4) If there ARE new changes, re-generate
That would prevent unnecessary load on the server over multiple requests/users.