...several minutes later ... ;-P , I got the gist of it. First of all, testing something "concurrent" with sqlite isn't properly fair. SQLite sucks at being concurrent.
That being said, assignment is sub-optimal (the gist of what you're trying to point at). Clicking here and there with 3 workers and a total of 30 tasks, the "final" result is worker1 --> 13 tasks processed worker2--> 9 tasks processed worker3 --> 8 tasks processed ... while you'd like to see - hypotetically - the following: worker1 --> 10 worker2 --> 10 worker3 --> 10 Now, where I think the assignment is sub-optimal is that the grand-total of available workers is fetched from the list of ACTIVE ones, instead of "considering" only the ones that are ACTIVE but NOT processing any task. The "historic" reason is that the algo tries to be fairly straightforward in the sense that each worker processing a group gets equal chances to process the tasks (not so clear-to-read given that different group_names can be assigned, but that's offtopic). This means that on every "assignment loop" any non-running task (including yet ASSIGNED) is correctly picked, "examined" and thrown around available workers... BUT... that may be busy processing another task in the meantime The problem is kinda more obvious when: - tasks are a few - each task takes a long time to be processed - only "long" tasks are queued that is basically the "situation" you're in. Let me see if I can squeeze a taddle bit more "intelligence" in the algo. I'll get back to you ASAP. -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
