#8212 closed defect (duplicate)
Trac ticket processing extremely slow
| Reported by: | Owned by: | ||
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | ticket system | Version: | 0.11.2.1 |
| Severity: | normal | Keywords: | restrict_owner |
| Cc: | Branch: | ||
| Release Notes: | |||
| API Changes: | |||
| Internal Changes: | |||
Description
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?
Attachments (0)
Change History (9)
comment:1 by , 16 years ago
| Keywords: | needinfo added |
|---|---|
| Version: | none → 0.11.2.1 |
comment:3 by , 16 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
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.
comment:4 by , 16 years ago
| Component: | general → ticket system |
|---|---|
| Keywords: | restrict_owner added; needinfo removed |
| Resolution: | fixed |
| Status: | closed → reopened |
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…
comment:5 by , 16 years ago
| Resolution: | → duplicate |
|---|---|
| Status: | reopened → closed |
… and as such, this ticket is a duplicate of #8034.
comment:7 by , 16 years ago
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 ;-)
comment:8 by , 16 years ago
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
comment:9 by , 16 years ago
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 ;-)
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?