Jonas Borgström wrote: > Christian Boos wrote: > >>> Yeah I think so, since it fixes a few long standing issues especially >>> Trac's bad habit of collecting a large number of databases connections >>> and never releasing them. >>> So unless someone objects I'm planning to commit this to trunk. It's a >>> bit too dangerous to backport this to 0.11-stable this late in the game. >>> But if it works well in trunk I think it would be a good candidate for >>> 0.11.1. >>> >>> (I've attached an updated version with some cosmetic changes) >>> >>> >> I've tested it, and found a bug by which the _available lock could be >> released more than once (patch attached). >> > > Good catch, I blame python's silly tab indentation for that bug ;) > > >> Once patched, tracd on Windows with Pysqlite 2.4.1 seems to work fine, >> though more likely to trigger the timeout error: >> - when I attempt three dozen concurrent requests on 2 environments >> served by the same tracd, I trigger approx. 6-7 timeouts (only 1 with >> the old pool) >> - with 2 concurrent tracd processes, each serving 2 environments and a >> dozen concurrent requests on each 4 targets, I trigger approximately 10 >> TimeoutError (only 1 with the old pool) >> >> I have yet to study the new code in more details, but I already saw that >> the thread affinity optimization for the dormant connections is gone, so >> that might explain the difference. >> > > 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 ;-) > Do you have any good idea how to make the pool size configurable? Using > a trac.ini option from the first environment accessing the pool would > work but that could potentially be very confusing and nondeterministic. > I think we could use a system environment variable here (e.g. TRAC_DB_POOL_SIZE), as we're dealing with a per-process setting, which is independent from the (Trac) environment(s) used. -- Christian --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
