nHydrate Stress Test

The stress test was performed on a AMD 3GZ Quad core machine with 8GB of RAM. The database had three tables: USER, USER_TYPE, and JOB. There were 48,652 users and 38,949 jobs. Each job has a parent user. The test was broken into 5 parts that were each run on a thread. There were 22,906 unique last names. There were no defined indexes except for primary keys and the user Id foreign key on job for its parent user. The tests performed were as follows.
  1. Aggregate count of users with a last name
  2. Select a list of users by last name
  3. Select each user by primary key
  4. Walk to related jobs for each user
  5. Walk to a parent user for each job

The results were as follows. The test was run in two minute increments and used 60-70% of the processor. About 700 records/second were pulled. This was from all operations, which averaged about 630 operations/second. An operation is defined as a database hit. The number of records pulled per transaction was small, so this reduced the overall selection average. 77% of users had less than 10 jobs, so the result set pulled was very small per operation. The time to pull 1,000 records is virtually the same as pulling 100 records. In other tests that were pulling tens of thousands of records at one time the results were retrieved in the 1-2 second range. Indexing of course improves results even more. The tests above were performed querying against last name which was not indexed.

These tests show that the DAL (data access layer) can handle quite a bit of database operations. If you assume that a user will hit the database 5 times / second (an overestimate) then this scenario still admits to handling 126 concurrent users (630/5). More realistically a user hits the database in batches, like loading some on-screen list boxes, client information, etc only every few seconds. So even assuming database access once/second/user still yields several hundreds of concurrent users.

Keep in mind that these tests were done on a sub-$1,000 machine, a desktop with application and database on the same box. In a production environment, you would most likely have a stand-alone database server with proper indexing. This would most likely include a RAID system, which helps tremendously. For further speed enhancement, you might also implement some sort of database load balancing if you are running a large-scale, enterprise application.

To conclude, these results were thrown together with no optimization whatsoever and they still show how performant is the system. In the real-world, you would be using a better machine with some simple and more complex optimizations. For these reasons we feel that the data access mechanism of nHydrate performs very well indeed, for the domain in which it was designed and runs.

Last edited May 9, 2010 at 6:54 PM by codetools, version 2


gbarborak May 13, 2010 at 2:30 AM 
Thanks for the info. I'm very interested in this topic. Greg and I work together and I'm very impressed so far with the ease of nHydrate. However, as Greg has pointed out, the results we are seeing are unacceptable for production, medium size database, and pretty good hardware. We have maxed out CPU and chocked up the application server when we hit 35+ concurrent users doing a lot of transactional activity that you would expect from an HR type application.

I would like to point out that we have a fairly large application running on the same server using the traditional 3-tier architecture. sprocs, and Enterprise Practices library for dataaccess and we are able to hit 200+ concurrent users with low CPU utilization on a database that's around 10GB in size with millions of rows.

A huge bonus for working with nHydrate is the fact that it generates the sprocs. I'm assuming that the DAL uses these and there would be benefits from the SQL Server optimizer. Do you have more details on how the DAL executes these? We see very high CPU utlization on the application server.... SQL Server CPU is good, so data access seems to be nominal.

Thanks again!