The file is read in bit, get the same time if I using SQL also... Seems like the context.endBulkEntryTransaction() does not get recorded in the AR_SERVER_STAT_API_TIME server statistic option. The statistic are the same before and after the call has been initiated
Need to hunt down more examples... Regards, Jarl 2009/8/17 Lyle Taylor <[email protected]>: > While you're at it, it may help to add some more detail here. Is the basic > structure of your program like this: > > Timing Point A) > > Begin Bulk Transaction (optional) > > Timing Point B) > > LOOP - Create Entry > > Timing Point C) > > Commit Bulk Transaction (optional) > > Timing Point D) > > There are three basic parts, with four points to use when measuring time. If > that matches your program's basic structure, then it's important to know > where you're measuring your times. If you're simply measuring the time > elapsed between points A and D (essentially, the entire execution time), that > may not be granular enough to isolate differences. Based on your last > e-mail, it sounds like you might be interested in the time it takes to get > from point B to C (processing the entire loop of 10,000 records) with and > without a bulk transaction and with either a regular or a display-only form. > Is that correct? > > One other item to consider is how you're reading in your csv file. Are you > reading it in all at once and then processing the records, or are you reading > it in line by line as you call the Create Entry functions? If the latter, > you'll probably get more consistent or accurate timing results if you read > the entire file into memory and then process the records rather than reading > line by line as you go, because other disk operations may interfere with > reading the file efficiently, and no two runs will be alike. > > Lyle > > -----Original Message----- > From: Action Request System discussion list(ARSList) > [mailto:[email protected]] On Behalf Of Jarl Grøneng > Sent: Monday, August 17, 2009 2:36 PM > To: [email protected] > Subject: Re: Wierd behavior with Java API -> ar-server > > I'll set up some more automated tests tomorrow, its too late for this > kind of things over here :-) > > -- > Jarl > > > > 2009/8/17 Lyle Taylor <[email protected]>: >> If you run each of the scenarios multiple times and average the times, do >> you still see a 25% (or 20%, depending on how you figure it) difference >> between 1 & 2 and 3 & 4? >> >> Lyle >> >> -----Original Message----- >> From: Action Request System discussion list(ARSList) >> [mailto:[email protected]] On Behalf Of Jarl Grøneng >> Sent: Monday, August 17, 2009 2:01 PM >> To: [email protected] >> Subject: Re: Wierd behavior with Java API -> ar-server >> >> 2009/8/17 Lyle Taylor <[email protected]>: >>> Jarl, >>> Your comment that the difference between 1 and 2 is due to one commit to >>> the database is incorrect. That end is the same - the difference is in the >>> network latency due to 1 vs 10,000 API calls across the network. That's >>> the exact same difference that you see between 3 & 4. >>> >> >> Did a new test-run, and the commit in example 2), with bulk >> transaction took approx 18 seconds. >> >> 2009-08-17 21:52:50,593 DEBUG [main] ARImport (ARImport.java:365) - >> Start bulk commit >> 2009-08-17 21:53:08,203 DEBUG [main] ARImport (ARImport.java:372) - >> End bulk create, sending all requests to AR Server >> >> >> The network latency should be very small since the client, server and >> database is on the same machine (as I wrote in my first email) >> >> It is 25% difference between 3-4 and 1-2 (16 seconds vs 20 seconds) >> >> -- >> Jarl >> >> _______________________________________________________________________________ >> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org >> Platinum Sponsor:[email protected] ARSlist: "Where the Answers Are" >> >> >> NOTICE: This email message is for the sole use of the intended recipient(s) >> and may contain confidential and privileged information. Any unauthorized >> review, use, disclosure or distribution is prohibited. If you are not the >> intended recipient, please contact the sender by reply email and destroy all >> copies of the original message. >> >> _______________________________________________________________________________ >> 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" > > _______________________________________________________________________________ > 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"
