On Dec 12, 2007 5:05 PM, Jeff Gerritsen <
..hidden..> wrote:
Chris and et al,
Back in 1991 I was working for a vegetable seed company using an AS/400. I
created a custom shop floor work order interface and created a background
queue to process each work order and break them up into individual
transactions the shop floor system (PRISM) understood. The system worked
well for over 10 years until they migrated to SAP (that's another
discussion - let's just say SAP is the first company to name its product
after what they do to their customers...).
The only additional idea I can offer is too offer a configuration option to
turn on background processing or leave it off.
Ok. Currently in /trunk by default all payments get entered directly. Currently you have to throw a switch via psql to get it to queue them. low-end customers almost certainly won't need this feature so there is no reason to give them something which could require that one keeps a closer eye on things.
Secondly, would adding an option to process 1, 2, or more threaded queues
balance throughput with performance or would the 2nd and more thread queues
hammer the db too hard?
Currently some portions of the workflow really hammer the web server really hard, while other parts of the workflow hammer the db really hard. Seems pretty balanced ;-)
BTW, could this idea evolve into something we can use modPerl to process, and
would there be benefit to using modPerl?
Probably would be some benefit, but in the problem cases, the issue has to do with time taken to format info from the db for human consumption. For example, pages which list thousands of transactions. Mod_perl has the most benefit when you have a lot of small hits on the system while in this case, it probably doesn't make a lot of difference (mod_perl would be a strong improvement for the POS side, however, since it would reduce latency).