[trac] Performance for last week?
First after disabling the trac source browser for most of the week here's the new breakdown of the top ten sections the web server spent time on (including www.boost.org): total_time = 319654701.643986 43.88 140251178.52 /svn 43.88 140251171.39 /svn/boost 42.47 135748391.81 /svn/boost/!svn 40.86 130621926.05 /svn/boost/!svn/vcc 40.86 130621926.05 /svn/boost/!svn/vcc/default 27.50 87894354.72 /trac 26.23 83846699.34 /trac/boost 14.81 47331832.95 /doc 14.26 45569562.87 /doc/libs 10.90 34846318.37 /style-v2 As you can see trac is no longer at the top of the list. And SVN is taking up almost half the time. Which is to be expected since many SVN interactions take considerable clock time to complete as data is sent to clients. So big questions with respect to last week: * Is trac performance to an "acceptable" point? * Do you miss the trac source browser, and desperately want it back? And now regarding SPAM.. I did some updates of the spam modules that improve overall performance, the dns sub-module was know to cause global trac delays. I was hoping to introduce CAPTCHAs with the updates.. But there was a problem with the one I got yesterday. I'll try a new update tonight and hopefully we can really cut down on the spam once and for all :-) PS. No I haven't looked at what, if anything, needs to get done to reduce the svn times. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
On 12/6/2010 5:59 PM, Rene Rivera wrote:
First after disabling the trac source browser for most of the week here's the new breakdown of the top ten sections the web server spent time on (including www.boost.org): <snip>
Thanks for working on this, Rene.
So big questions with respect to last week:
* Is trac performance to an "acceptable" point?
Slightly less horrible perhaps (hard to say), but I did get another "database is locked" error today while trying to view a changeset. I think it was this: https://svn.boost.org/trac/boost/changeset/66805 Then when I click on one of the links there (e.g. https://svn.boost.org/trac/boost/browser/trunk/boost/proto/transform/make.hp...), I get an error. I guess that's because you removed that plug-in, is that right?
* Do you miss the trac source browser, and desperately want it back?
I guess I do miss it. It's especially annoying that trac is serving up links that are now broken, and I'm still getting database-is-locked errors. Is there any way to profile page requests, see which are taking the longest, and where they're spending their time? -- Eric Niebler BoostPro Computing http://www.boostpro.com
On Tue, Dec 7, 2010 at 9:46 AM, Eric Niebler <eric@boostpro.com> wrote:
On 12/6/2010 5:59 PM, Rene Rivera wrote:
First after disabling the trac source browser for most of the week here's the new breakdown of the top ten sections the web server spent time on (including www.boost.org): <snip>
Thanks for working on this, Rene.
+1
So big questions with respect to last week:
* Is trac performance to an "acceptable" point?
Slightly less horrible perhaps (hard to say), but I did get another "database is locked" error today while trying to view a changeset. I think it was this:
https://svn.boost.org/trac/boost/changeset/66805
Then when I click on one of the links there (e.g. https://svn.boost.org/trac/boost/browser/trunk/boost/proto/transform/make.hp...), I get an error. I guess that's because you removed that plug-in, is that right?
I just tried to make some changes myself to a ticket and I see that the server's utilization is up again to 11.38 -- that's not good, but when the anonymous ticket filing was turned off I didn't see the load average number to be going above 1.x. Maybe we should just disable anonymous issue posting? Also I did get an error submitting a comment to an issue, but not the database is locked error that you're getting Eric.
* Do you miss the trac source browser, and desperately want it back?
I guess I do miss it. It's especially annoying that trac is serving up links that are now broken, and I'm still getting database-is-locked errors. Is there any way to profile page requests, see which are taking the longest, and where they're spending their time?
I personally don't miss it. Eric, as far as profiling goes, I'm not positive that Trac has that capacity. Although Python has a profiling module, running Trac under a Python profiler would really kill performance. If you think it's unacceptable now, then turning on profiling is going to be quite annoying. Maybe we should get Google Analytics instead into the pages to at least have a better insight into the usage scenarios when it comes to browsers going through the site. This would give us end-user statistics, which would also be useful to confirm/debunk assumptions we're making about Trac usage. HTH -- Dean Michael Berris deanberris.com
participants (4)
-
Dean Michael Berris -
Eric Niebler -
John Maddock -
Rene Rivera