Databases Reference
In-Depth Information
accessed data is always kept in memory so that subsequent accesses are fast (no
disk access is required to return the data). In this performance test scenario, the
systems were all restarted to measure a “fresh” system.
The benchmark should have included some time to prepare the database sys-
tems by running the benchmarks once without measuring performance. Once
the highly accessed data is in memory, it remains there for the most efficient
access during runtime.
The database application in this case study supports a distributed sales team. The
application is GUI based and has multiple options with regard to the type of sales
information that can be queried, such as sales leads by territory, sales leads by
product, existing customers by product purchased, and revenue by territory. The
application will be used by a maximum of ten concurrent users.
Environment Details
The environment details are as follows:
•
The application is ADO.NET and is running on an application server.
•
The database server is an Oracle 11g shared server running on AIX 5.3.
•
The client machines are running the .NET Framework 2.x and a variety of
Windows operating systems, such as Windows XP and Windows Vista.
•
The application is deployed in a WAN environment.
•
The application is using connection pooling and statement caching.
•
CPU and memory are plentiful on both the middle tier and database server.
•
The database provider is DataDirect Technologies ADO.NET data provider
for Oracle. Here's the connection string:
"Host=Accounting;Port=1433;User ID=Scott;Password=Tiger;
Server Type=Shared;Load Balance Timeout=0;Wire Protocol Mode=2;
Enlist=False;Batch Update Behavior=ArrayBindOnlyInserts;
Pooling=True;Cursor Description Cache=True;Max Pool Size=10;
Connection Reset=False;Fetch Array Size=128000;
Session Data Unit=8192"
