Christian Boos wrote: >> I don't have access to Windows to test this right now but can you check >> if this "regression" is simply due to the fact that the total pool size >> in your test is smaller with the new code. With the old pool each tracd >> process would contain two pools (one for each env) with 5 connections >> each and the new code uses only one pool. What happens if you increase >> the hardcoded pool size to 10? >> > > That helped, in the first case (1 tracd, 2 envs) I didn't get timeouts > anymore. > In the second case (2 tracds, 2 envs), only 4. > But in both scenarios, in some runs I also had a "database is locked" > which touched 10-12 requests. > > Tricky, as always ;-)
Indeed, but that many concurrent threads in a single python process will never perform particularly well due to GIL. But I'll guess the lock contention is a bit worse since there's a single lock garding the pool for all environments. Anyway, I still believe the new pool will perform equally well or better for more use cases so I've gone ahead committed in to trunk to get some more testing. http://trac.edgewall.org/changeset/7190 The default pool size is now 10 connections but can be configured using the TRAC_DB_POOL_SIZE environment variable. Btw, do you or someone else know why we still only mark sqlite connection on windows as poolable? http://trac.edgewall.org/browser/trunk/trac/db/sqlite_backend.py#L154 / Jonas --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en -~----------~----~----~----~------~----~------~--~---
