A couple of thoughts:
My first guess would be that you are running the entire thing in a
single transaction. I don't know if that is the case, but that would
explain why subsequent orders are taking longer to process. The more
that is involved in a transaction, the longer processes related to it
will take (because of temporary information the database must process,
etc).
To pin this down better you should also find out how much time is
being spent in the database versus the app server.
As a general recommendation you might code this so that it runs these
10 at a time, ie 10 parallel threads. This can be done by having a
parent service that goes through the list and a sub-service that
processes each, and have the parent service do 10 sub-service calls
asynchronously, wait for all 10 to finish, and then do the next ten
(until there are less than 10, then do whatever is left). There is a
lot of waiting among threads and chances are doing one at a time your
system resource utilization will be really low (ie small CPU
utilization percentage). I think doing this would touch OFBiz code, as
both parts are in there, but where the code is doesn't matter. If you
want to contribute it back chances are someone will help review and
test it and get it into the trunk.
-David
On Jun 18, 2008, at 9:50 AM, Dave Tenerowicz wrote:
We are seeing some issues in creating large volumes of Orders from
shopping lists. In the production environment, we can see as many as
10,000 shopping list entries processed in a single run, and we are
seeing extremely long processing times.
To try to find the bottleneck we have logged times for each
processing step, and found a weird anomaly. As you would expect,
most of the processing time is spent in the Create Order step.Here's
the weird part - in a small sample the first Order was created in
3.704 seconds. By the 12th shopping list entry, the order creation
step took 12.258 seconds. By the 39th shopping list record, the
order creation step took 27.062 seconds!! This pattern of increasing
processing time for each successive order appears to continue
throughout the run.
We are baffled as to why this is occurring. Has anyone else noticed
this - or does anyone have an idea what could be causing this?
Any suggestions would be appreciated.
--
Dave Tenerowicz
[EMAIL PROTECTED]
Office: 303.493.6727
Mobile 303.906.6116
Fax 303.814.8331
Visit us at http://www.salmonllc.com
For ERP Information:
http://www.salmonllc.com/Jsp/vanity/ERP_CRM.jsp?nav=2&NavBarId=ERP_CRMServices
