Enterprise Library Test Guide - Willy .Net
Enterprise Library Test Guide - Willy .Net
Enterprise Library Test Guide - Willy .Net
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
232<br />
<strong>Enterprise</strong> <strong>Library</strong> <strong>Test</strong> <strong>Guide</strong><br />
In the scalability tests for the Data Access Application Block, the processor queue<br />
lengths began to lengthen as the number of concurrent users increased and the CPUs<br />
reached their limits. Values for processor queue lengths were initially zero and increased<br />
to between 7 ms and 10 ms after the CPUs could no longer support any more<br />
users.<br />
The servers are always CPU bound. Other than the processors, there are no other<br />
dependencies that can cause bottlenecks. The change in memory size between the 2<br />
processor configurations and 4 processor configurations (for both the 32-bit computers<br />
and 64-bit computers) did not affect the relevant measurements.<br />
Here is a summary of the results:<br />
●<br />
●<br />
●<br />
●<br />
●<br />
●<br />
The 64-bit computers outperform the 32-bit computers by 45 percent for the<br />
transactions per second measurement and for the total transactions measurement.<br />
For all cases shown in Figure 7, there should be no I/O activity when the % Disk<br />
Time counter is less than 7 percent.<br />
The 32-bit computers with 2 processors could not support more than 10 concurrent<br />
users. The 32-bit computers with 4 processors could not support more than 50<br />
concurrent users. The 64-bit computers with 2 processors could not support more<br />
than 10 concurrent users. The 64-bit computers with 4 processors could not<br />
support more than 50 concurrent users. Scalability increases as the number of<br />
concurrent users were added to the test mix when bigger deltas were observed<br />
between 2 processors and 4 processors (32-bit computers and 64-bit computers).<br />
The servers’ working sets always require less than 40 MB for all configurations.<br />
Measurements of the memory required by the working sets and the values of the<br />
CLR % GC performance counter indicate that memory size did not cause any<br />
bottlenecks during the scalability tests. All bottlenecks were caused by the limit to<br />
the number of users the CPUs could support.<br />
The Logging Application Block has good scalability. This is largely due to the low<br />
number of contentions per second. The value of the % Contention rate/sec performance<br />
counter was approximately 8 per second with saturation of CPU in all<br />
cases and between 2 percent and 3 percent below saturation levels.<br />
Analysis of Caching Application Block Scalability <strong>Test</strong><br />
Figure 8 is a graph of the test results. It shows the results for both the 32-bit computers<br />
and 64-bit computers, each with 2 processors and then 4 processors.