Hi Scott, Actually, my main concern is more on the processing of a document. This usually involves alot of inserts and updates at the very least. I think the bottleneck is more in the database inserts/updates. Indeed, scaling up our hardware (and alot of database load balancing/clustering and indexes) could help speed up these processes. As for querying a large set of result sets, we had problems dealing with the current implemtation of entity list iterator. There was a linear time difference for requesting for a small number of result sets as the total number of rows grow to the hundred thousands. We modified the sql processor to use limit and offset to make requesting time constant regardless of the number of rows the entity would have. The limitation of using a "non standard" sql command was acceptable for us since we wouldnt be changing our databases anyways.
--- Ian Tabangay On Wed, Nov 11, 2009 at 4:02 PM, Scott Gray <[email protected]>wrote: > Hi Ian, > > I didn't say OFBiz wasn't intended to handle this sort of load, I just said > that the purchase order code may not have been optimized for it. I have no > doubt that OFBiz can handle what you're describing but you may find portions > of the code could be improved to speed things up a bit, like using the cache > where appropriate, using the entity iterator rather than retrieving full > lists for large result sets, improving queries to make better use of > indexes, etc. After that it really just comes down to your hardware. > > Regards > Scott
