On Friday 05 June 2009, anatoly techtonik wrote: > Performance test needs real DB with big data table. When people switch > from old Trac version to a new one and notice serious performance > decrease they usually already have about 1000 tickets inside.
> This leads to conclusion that read-only tests are better be executed > by final users on their production DB (in a safe testing environment > with all external output - email etc. turned off) with profiling > turned on to gather statistics on lockups and catch other surprises > that can only occur when several processes are executed concurrently. At work we have a system with over 28,000 tickets and 140,000 svn revisions. (Currently using the sqlite backend, though we're seriously considering seeing if we can switch to postgres). There's a definite slowdown between 0.10 and 0.11 (further aggravated by the WYSIWYG plugin causing a reload of every page with text entry). If that's a useful setup to test and there's a test that's relatively simple to set up, I could run tests some evening/weekend. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to trac-dev@googlegroups.com To unsubscribe from this group, send email to trac-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en -~----------~----~----~----~------~----~------~--~---
