Trac ticket processing extremely slow

[Chris Toney <ctoney@…>]

Hello,

We have trac 0.11.2.1-1 install using sqlite running on a powerful machine (Dual 2.0Ghz processors and 8GB RAM) running CentOS5.2 x64. We are seeing extremely slow response (from 15-30 seconds) for page loads when opening a new ticket and viewing an existing ticket. We have queried the DB directly and responses come back in ms, so no issue with the DB responding slowly. Our entire DB is about 150MB. Further investigation looks like there are a ton of queries being sent to the DB on new ticket creation and when clicking on an existing ticket.

System Information:
CentOS5.2 x64
python 2.4.3-21
sqlite 3.3.6-2
mod_python frontend

We are considering moving to postgresql if this will resolve the issue. How easy/painful is that process? Is there any chance of data loss?

[cboos]

Sorry for not getting back to you earlier.

You didn't talk about the machine load, but it doesn't look like this is the problem.
SQLite should perfectly be able to fit the bill.
I rather think about a duplicate of #7940.

Is the performance also that terrible just after restarting the web server (which web front-end do you use, btw?), or does that only happen after a while?

How does changing the log level affect the performance?

[cboos]

Damn numbers, I meant to say "duplicate of #7490" ;-)

[anonymous]

Resolved this - it was a configuration issue.

The setting for restrict_owner in the trac.ini was set to true which caused either opening new tickets or displaying existing tickets to take from 5-25 seconds to display. Setting this vaule to false reduced the display time to ~1 sec for both. We installed the autocompleteusers component for the assign to field and everything is processing as expected. This ticket can be closed.

[cboos]

Hm, not fixed as we didn't change anything to the code.

Quite the opposite, the above suggests that the restrict_owner stuff is seriously broken...

[cboos]

... and as such, this ticket is a duplicate of #8034.

[anonymous]

you are right - something seriously wrong with restrict_owner

[cboos]

If you don't mind, you could try the latest patch from #4245: attachment:get_users_with_permission.groupprovider_fix.patch:ticket:4245​
(the patch still applies on 0.11-stable and the tests pass).

It seems that you have the ideal environment for verifying if the patch helps or not ;-)

[anonymous]

Sure, i'll fire up my test system and give it a shot. I do have to say that all the users really like the new autocompleteusers component, it's very nice

[cboos]

Actually I had a problem while running the tests: the patched file was not readable (Windows Vista, you know) and somehow Python 2.4 which I used for the test picked up the .pyc file which was previously there (i.e. the unpatched code).

Well, to make it short: the patch actually reintroduces the problem #4630 - many thanks to our functional testing team for the regression test ;-)