hi,
My environment is as follows : a virtual machine with 16 virtual processors and 64 GB memory. I have a small test csv file with hundred and sixty thousand rows. I am spinning 16 threads at the rate of one thread per CPU, thus, each sharing a work load of ten thousand rows. Each of the threads is converting ten thousand rows to equivalent in-memory DataTable. And, until this stage all the processing is happening in few seconds (in under 7-10 seconds from start of program, and at this point in time, I have a collection of 16 in-memory Datatables, each holding ten thousand rows). So, Disk IO ends here at this stage. From now on, CPU bound processing happens. Each of the 16 threads continue to loop through their respective work-load of ten thousand row in-memory DataTable and connects to Database to update one of the columns in their respective in-memory Datatables. The overall throughput is observed to be 90 minutes for these ten thousand rows, which is roughly 100 rows per minute. Each of the 16 threads takes exactly the same amount of time and within these common 90 minutes all the 16 threads process their respective work load of ten thousand rows. This looks very very low throughput. A closer look at the Database turn-around times is verified to be very fast, within a few milli/micro seconds the Database is able to respond back. There is no Disk IO within the loop. As soon as the value is looked up in the Database, the in-memory Datatable is updated. And, each of the these instructions themselves are happening extremely fast (from times logged). Whereas, it has been observed that between successive programming instructions within the loop, there is a short delay, probably due to context/thread switching.
Question-11 : In a hardware setup of 16 virtual processors with 64 GB memory, and the program spinning threads at a ratio of 1:1 (and almost zero user programs running in the VM), why is context switching happening at all? Question-2: Can Async sort of TPL Asynchronous programming help here - which I believe is of little help (please correct me otherwise), because there is nothing the program has to do while waiting for the response from Database. There are hardly 3 or 4 instructions within the for-loop processing the ten thousand row in-memory Datatable, and each of these programming instructions is dependent on the completion of the previous programming instruction, there is nothing an instruction X can do out-of-sync while its predecessor instruction (X-1) is still being processed. These 3 or 4 instructions in the for-loop have to go sequentially. X, X+1 , X+2 are happening extremely fast in milli/micro secs. It seems the root cause is the short delay between some X and X+1 or (x-1) and x or sometimes (X+2) and (X+3), giving an overall through put of just over 1 row per second.
Could you please share your views?
thank you
My environment is as follows : a virtual machine with 16 virtual processors and 64 GB memory. I have a small test csv file with hundred and sixty thousand rows. I am spinning 16 threads at the rate of one thread per CPU, thus, each sharing a work load of ten thousand rows. Each of the threads is converting ten thousand rows to equivalent in-memory DataTable. And, until this stage all the processing is happening in few seconds (in under 7-10 seconds from start of program, and at this point in time, I have a collection of 16 in-memory Datatables, each holding ten thousand rows). So, Disk IO ends here at this stage. From now on, CPU bound processing happens. Each of the 16 threads continue to loop through their respective work-load of ten thousand row in-memory DataTable and connects to Database to update one of the columns in their respective in-memory Datatables. The overall throughput is observed to be 90 minutes for these ten thousand rows, which is roughly 100 rows per minute. Each of the 16 threads takes exactly the same amount of time and within these common 90 minutes all the 16 threads process their respective work load of ten thousand rows. This looks very very low throughput. A closer look at the Database turn-around times is verified to be very fast, within a few milli/micro seconds the Database is able to respond back. There is no Disk IO within the loop. As soon as the value is looked up in the Database, the in-memory Datatable is updated. And, each of the these instructions themselves are happening extremely fast (from times logged). Whereas, it has been observed that between successive programming instructions within the loop, there is a short delay, probably due to context/thread switching.
Question-11 : In a hardware setup of 16 virtual processors with 64 GB memory, and the program spinning threads at a ratio of 1:1 (and almost zero user programs running in the VM), why is context switching happening at all? Question-2: Can Async sort of TPL Asynchronous programming help here - which I believe is of little help (please correct me otherwise), because there is nothing the program has to do while waiting for the response from Database. There are hardly 3 or 4 instructions within the for-loop processing the ten thousand row in-memory Datatable, and each of these programming instructions is dependent on the completion of the previous programming instruction, there is nothing an instruction X can do out-of-sync while its predecessor instruction (X-1) is still being processed. These 3 or 4 instructions in the for-loop have to go sequentially. X, X+1 , X+2 are happening extremely fast in milli/micro secs. It seems the root cause is the short delay between some X and X+1 or (x-1) and x or sometimes (X+2) and (X+3), giving an overall through put of just over 1 row per second.
Could you please share your views?
thank you