Hi Scott, No its not the customers who are ordering. These are purchase orders of the 500 facilities (or stores). I think its mostly the sheer number of inserts/updates that is required to complete the process. I did a similar application that inserts/updates to the same entities directly to the database to complete a purchase order and the results, as compared to how ofbiz does, it wasn't significantly faster. Right now Im finding ways to divide the work and/or remove this load from the main ofbiz server to give way for other processes that will be maintained by ofbiz. What I wanted to try is to implement ofbiz as a tool to manage inventories and sales of multiple stores; about 500 stores selling about 18,000 products doing at least 1 sales transaction (average of 4 line items) per minute. Stores make purchase orders everyday for about 800 products each day. You mentioned that ofbiz wasnt intended for this kind of use? What would you say could be managable by ofbiz OOTB (or with minor changes)?
--- Ian Tabangay On Wed, Nov 11, 2009 at 12:39 PM, Scott Gray <[email protected]>wrote: > Hi Ian > > My guess is that because most people don't order 1000 different products in > a single purchase order the code has never been optimized to deal with that > scenario. The framework itself can certainly handle it so it's really just > a matter of finding the bottlenecks and improving the offending code. If > you can locate the portions of code that are slowing things down it will be > easier to offer suggestions on how to improve it. > > Regards > Scott > > HotWax Media > http://www.hotwaxmedia.com
