Multi Threaded Testing Utility
I had an engineering manager ask me if I could build him a testing tool, that would measure latency in an application that connected to a database. The criteria was something like:
Thread 1: Use ADO.Net to connect to an Access database, perform a sumple select query, bind the dataset to a grid, calculate the time from request to bind, and update a graph on a form. This routine runs continous.
Thread2: Use ADO.Net to connect to a SQL Server database, perform an update query, calculate the the time from request to response, and update a graph on a form. This routine runs continous.
Thread 3: Use ADO.Net to request an XML file from a Web Service, which connects to an Oracle database, executes a procedure, returns the data in an XML file via SOAP, calculate the time from request to response, bind the results to a seperate datagrid, and update a graph on a form. This routine runs continous.
The idea is to see where bottle necks occure in simple database connections. A typical application in this environment may need to connect to all three sources in a transaction. The engineer wanted to see if threading was an option or individual functions within the same process.
So, what are your thoughts? The results, were scary. After spending hours trying to debug crashes (which turned out to be some of my fault and some of ADO), that the machine the application is running on impacts the performance more than the actual processes of the application itself.
Example. We first tried it on a 733 Mhz Pentium III machine with 256 MB of ram. The app crashed after only about 5 minutes. Next on a PII Dual 800 something Mhz with 1.5 GB ram, exceptional performance (obviousley), and on a Toshiba 8100 with 128 MB ram... oh my, bad idea... anyway, we never really made any scientific breakthoughs. We did discover though, that the idea of multi-threading an application for database purposes, didn't give us the high performance that we were looking for. So, we'll keep looking.