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.
- Aggregate count of users with a last name
- Select a list of users by last name
- Select each user by primary key
- Walk to related jobs for each user
- 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
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.