Hi IanMy 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 On 11/11/2009, at 5:16 PM, ian tabangay wrote:
oh actually im talking about processing (as in completing) a order with 1000 items. Im looking for ways to tweek ofbiz to make it faster. Has anyone had the same experience? Maybe on a different document (Shipment, Returns, etc)?Id like to get some input. Currently Im testing ofbiz with about 500facilities, 1,500 suppliers, 18,000 products and 300 product categories. Itsquite a load so Im checking if ofbiz can handle it. Thanks for any input anyone can provide. --- Ian Tabangay On Tue, Nov 10, 2009 at 11:00 PM, Matthieu Bollot < [email protected]> wrote:Hi, which ofbiz version/screen are you using ?I'm fighting with LookUpBulkAddSupplierProducts.groovy used to purchaseorder for a few days, because it doesn't work in trunk since r831676 And actually, I think that it needs a complete rewrite but it's quite difficult using Delegator and xml forms.The best thing would be to use sql row_number, but even if we could use it, there will be some pagination problems because the first number ofproducts is not the same as the final one…I'm working on it, but I'll not be able to provide something quickly, soif anybody else want to give a try. Regards, Matthieu.
smime.p7s
Description: S/MIME cryptographic signature
