[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: LedgerSMB Scalability Bottleneck-- proposal



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.

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?

BTW, could this idea evolve into something we can use modPerl to process, and 
would there be benefit to using modPerl?

Thanks,

Jeff Gerritsen

On Tuesday 11 December 2007 22:51:36 Chris Travers wrote:
> One of the issues that LedgerSMB can run into in larger environments is
> that large processes can run into client timeout issues, especially when
> large amounts of data are passed back and forth.
>
> <snip>
>
> Does anyone have any better ideas?
>
> Best Wishes,
> Chris Travers