Database Reference
In-Depth Information
Workshop
In this workshop, we walk through a testing scenario of scaling the application using LoadRunner. The idea here, like
in most tests, is to achieve the optimal performance goal defined by business.
Step 1
This step is an information-gathering step. What is the goal of this test? What are the response time requirements
for the critical areas of the application? What is the maximum number of concurrent users expected during go
live, 3 months after go live, 6 months after go live, and 12 months after go live? These numbers will help testing the
application for throughput and response times.
Step 2
When testing the application for scalability, the complete path of the transaction should be included in the test,
meaning from the user interface, where the users request for data or enter orders, to the physical database, where data is
persisted and or retrieved. This is unlike the Phase V test where only the database and the SQL statements were replayed.
To replay the front to back flow of data, tools such as LoadRunner should be used. LoadRunner can capture
user screens with data being entered or retrieved and the exact screen can be repeated using multiple concurrent
transactions.
Step 3
Using LoadRunner, the number of concurrent users and the ramp up time can be specified to create a user workload.
Whereas in the various functional areas, the frequency of transactions, the think time, and so forth, should be
consistent with real-life production environments.
Record the findings in a table (illustrated in Table 4-5 ) or spreadsheet for documentation, charting the
comparisons as we go through other tests or when these operations are repeated at a later date.
Table 4-5. RAP Phase VIIā€”Data Collection Table
Test #
Date
Time
# of Users
Duration
# of Db
Servers
# of App
Servers
Test
Description
Status
Table 4-5 is used for recording the findings from the test; the columns help us record the various matrixes that
were used and collected from the test:
Test # : There will be a serious of tests, so this column will record the test number. It will help
us reference this test by the number.
Date and Time : Record the date and time when the test was executed.
# ofUsers : This lists how many users will be involved/simulated in the test. If you recall our
earlier discussion, LoadRunner can be used to simulate workload patterns based on user
navigation patterns captured from the current production users.
Duration : How long did the test run? Once again, using LoadRunner, the amount of time
the test will be executed can be preset. Not always will or may the test run for the expected
duration. It could fail because of various reasons, such as reaching the maximum capacity
of the servers, wrong configuration of parameters, and so forth. If desired, the duration
column can be expanded to list target duration and actual duration.
 
 
Search WWH ::




Custom Search