Merge it your own way -- Followup on the test

 

After publishing the first test results on a previous post I got in contact with the product team to followup the test results. After redoing the test on real hardware and in a client - server scenario, the following result could be extracted from the tests.

As the following charts shows, the Merge statement outperforms the SQLCommand as well as the SQLAdapter methods even with increasing number of rows per test. In conclusion this means for the test and the setup and in a common conclusion (might differ in other scenarios), although the SQLCommand as well as the SQLAdapter are aware of the changed rows and which command to fire they are not as fast as the Merge statement. In comparison the Merge statement which needs to send all rows to the server to evaluate the changes and fire the appropiate commands scales better even with this overhead than the other methods.

 

The following charts though shows an interesting result (which can be compared to the first test), although being scalable with increasing row numbers, increasing row size does not scale well at all. The conclusion for this could be that the more data you want to send to the server per row the more you should consider using a client method (if appplicable) to sort out with row has to be changed on the server.

 

If anyone has additional questions, need the test setup or the resulting data in raw format (Excel) feel free to contact me.

Comments

• Anonymous
  July 28, 2008
  PingBack from http://blog.a-foton.ru/2008/07/merge-it-your-own-way-followup-on-the-test/

• Anonymous
  January 13, 2009
  Just wondering, did you play with the BatchSize property on the SqlDataAdapter? That is one of the cool benefits is the reduction of SQL Packets.  

• Anonymous
  January 15, 2009
  Yes, I did that according to the BatchSize for processing the data fomr the server I adjusted the BatchSize for the SQLDataAdapter. -Jens