Jarl, Let's hear it for LATENCY. The network kind.... (ok, there is a bit of savings on basic overhead with user checking and parameter marshalling and fewer TCP transactions (although they are different sizes) and other things like this because of fewer API calls). Total volume of data across the wire is the same, but it is many small packets (10,000 small) or fewer larger packets (xxxx larger with xxxx being how many things are in the bulk operation you are doing).
In your first example, the difference is about 20 seconds. In your second example, the difference is about 16 seconds. The difference between case 1 and case 2 is whether there is a write to the DB involved. Well, the DB write and commit is the majority of the time in these cases. In the bulk case, it is about 46 seconds of the time 4 seconds vs. 50 seconds. Interestingly, in the non bulk case, it is about 50 seconds of the time 20 seconds vs. 70 seconds. Now, with this, it looks like there is 4 seconds related to DB difference and 16 that is common and not related to DB difference. I would guess that the 4 second DB difference is small because of there being no data in the tables and probably small records and no other work so the extra commits you are saving (not saving anything from an insert or workflow perspective so it is just the multiple transaction aspect) are relatively small in this case. It is still 20% savings! The time savings on the network are relatively constant in this mix -- although if you have high network latency, you are saving even more. For example, say there were chunks of 100 operations in the bulk operations. That would mean 100 chunks. If you were talking about .25 second latency, you are talking about 100 * .25 or 25 seconds vs. 10000 * .25 or 2500 seconds in time for the savings on the network (notice how any overhead of the API calls is totally swamped by network time when there is latency). Again, fixed, but just a bigger number than the above. It is important to look at what the savings is in situations like this and where the savings is coming from. I cannot gaurantee that the numbers are all in the locations I note here, but the concept of what the bulk calls do and save and where the savings are (db vs. network) are correct. Also, it shows why the numbers that look odd at first glance are much more reasonable and make more sense. You are just swamped here with network and overhead issues that are taking the majority of the time while the DB side is efficient and giving you gain, but a lower percentage of the gain. I hope this helps explain what is likely occurring and how to interpret your data results. Doug Mueller -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Jarl Grøneng Sent: Monday, August 17, 2009 8:16 AM To: [email protected] Subject: Wierd behavior with Java API -> ar-server I have a JavaAPI program that reads a csv file, and import the data into a form 1) Import 10.000 records into a regular form, takes appox 70 seconds 2) Import 10.000 records into a regular form with bulkimport enabled , takes appox 50 seconds: The time gap between 1 and 2 is mainly one commit to the database. 3) Import 10.000 records into a display only form, takes appox 20 seconds 4) Import 10.000 records into a display only forrm with bulkimport enabled, takes appox 4 seconds. Why should it be that large difference between 3 and 4? AR server 7.5 patch 2 Oracle 10 (all figures on arserver on my laptop) -- Jarl _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:[email protected] ARSlist: "Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:[email protected] ARSlist: "Where the Answers Are"
