Enterprise Library Test Guide - Willy .Net

Testing for Performance and Scalability 231
●
●
●
Measurements of the memory required by the working sets and the values of the
CLR % GC performance counter indicate that memory size did not cause any
bottlenecks during the scalability tests. All bottlenecks were caused by the limit to
the number of users the CPUs could support.
Processor queue lengths began to lengthen as the number of concurrent users
increased and the CPUs reached their limits. Values for processor queue lengths
were initially zero and increased to between 7 ms and 10 ms after the CPUs could
no longer support any more users.
The Logging Application Block has good scalability. This is largely due to the low
number of contentions per second. The value of the CLR Contention rate/sec
performance counter was approximately 8 per second when the CPU was used at
its full capacity (close to 100 percent) and 2 percent to 3 percent when the CPU
was below its saturation levels. These are low numbers that demonstrate that
there were very few contentions during the scalability tests.
Analysis of Data Access Application Block Scalability Test
Figure 7 is a graph of the test results. It shows the results for both the 32-bit computers
and 64-bit computers, each with 2 processors and then 4 processors.
Figure 7 Scalability results for Data Access Application Block
The tests read one row of a database for each test cycle. There are no writes because
write operations can cause an increase in SQL Server I/O activity. In turn, this dependency
may affect the percentage of processor time that the application block can use.
The test should be performed without any dependencies that would prevent the CPU
from being used to its full capacity.