Throughput

3 views
Skip to first unread message

Nirmal Ramalingam

unread,
Jun 7, 2010, 3:15:56 PM6/7/10
to denver-infor...@googlegroups.com
How is the insert and update throughput shown in the monitor calculated? Is it over the entire session time or just according to the number of insert or update rows and the time taken to load it?

Tom Nats

unread,
Jun 7, 2010, 3:21:10 PM6/7/10
to denver-infor...@googlegroups.com
It's just a speedometer. rows per sec = rows inserted/update divided by the number of seconds that have passed.

We did notice that the throughput number is misleading a lot of the times. If your session starts out fast, that number is high and if it really bogs down towards the end, that number slowly comes down (based on the average) so it gives you a false sense of your actual throughput. The only true way of doing this to write down the number of rows, then when it updates, write it down again and divide the two. (Thanks to Lloyd on this..)

Nirmal Ramalingam

unread,
Jun 7, 2010, 3:33:53 PM6/7/10
to denver-infor...@googlegroups.com
More specifically, how is the time component considered?? If we have say 100,000 rows from the source and only 10 are inserts and the rest updates and the whole session takes 10 mintues to complete, then the rows/sec for the insert path is calulated as how many rows were inserted in the whole 10 mintues OR based on the 1 minute it took to load the 10 rows?

Sats

unread,
Jun 7, 2010, 3:58:08 PM6/7/10
to denver-infor...@googlegroups.com
It will consider the 10 mins.

Tom Nats

unread,
Jun 7, 2010, 4:00:24 PM6/7/10
to denver-infor...@googlegroups.com
Yea, if you look at the workflow monitor it says: Throughput (Rows/Sec).

So, for your target, if the session took 10min to finish, it would be the number of rows inserted divided by 600 seconds.

Nirmal Ramalingam

unread,
Jun 7, 2010, 4:06:36 PM6/7/10
to denver-infor...@googlegroups.com

If that is the case, look at the attached example. In this session, there are 1354 insert rows. The whole mapping took around 8 mins, that's 480 secs. If that is the case, the rows/sec is 1354/480 = 3 approx… and which is not what it shows.

throughput.JPG

Tom Nats

unread,
Jun 7, 2010, 4:11:12 PM6/7/10
to denver-infor...@googlegroups.com
Yes, but remember my earlier email, we had this same issue years ago. That is an average throughput. So, you hammered 800 rows right away at 30 rows a second then it slowed down to finally reach an average of 16.

Basically, to get the real throughput, you have to do the math that you just did.

Nirmal Ramalingam

unread,
Jun 7, 2010, 4:17:59 PM6/7/10
to denver-infor...@googlegroups.com
OK.. makes sense. Again in that example, the update throughput is higher than the insert. Does it tell me that the inserts are slower and something is wrong or it doesnt actually reflect a problem in the mapping?

Tom Nats

unread,
Jun 7, 2010, 4:40:40 PM6/7/10
to denver-infor...@googlegroups.com
It doesn't reflect anything. If the number of records were the same and the throughput was different, maybe that might show something but since they are just average, the number is just something to brag about at lunch...
Reply all
Reply to author
Forward
0 new messages