IBM System Verification Test for
iSeries with Domino 8.5.1
October, 2009
1 Overview
The IBM System Verification Test (SVT) objective is to execute a set of test scenarios against a test configuration that contains the key requirements and components that will create a load on the iSeries machine. This testing was performed using test scripts currently used by Domino SVT team. The system/performance testing can be used as a model for the capacity, configuration and costs for refreshing the Domino Server infrastructure. The initial testing will leverage the IBM test lab and resources to provide real world understanding of the performance and scalability of the Lotus Domino Server 8.5.1.
One's perception of system quality is governed under the statement of overall system reliability. A widely accepted definition of software reliability is the probability that a computer system performs its destined purpose without failure over a specified time period within a particular execution environment. This execution environment is known formally as the operational profile, which is defined in terms of sets of possible input values together with their probabilities of occurrence. An operational profile is used to drive a portion of the system testing. Software reliability modelling is therefore applied to data gathered during this phase of testing and then used to predict subsequent failure behaviour during actual system operations.
A reliability test is one that focuses on the extent to which the feature or system will provide the intended function without failing. The goal of all types of testing is the improvement of the reliability program with specific statements about reliability specific tests. Reliability is the impact of failures, malfunctions, errors and other defect related problems encountered by customers. Reliability is a measure of the continuous delivery of the correct service (and, the time to failure).
SVT's purpose of running Reliability tests was to ascertain the following:
· Data population for all parts of the infrastructure to force set limits to be achieved and passed
· Running sustained reliability scripts at >100% maximum capacity. Assessing :
· Breakpoints
· System stability pre and post breakpoint
· Serviceability
· Forcing spikes and anti-spikes in usage patterns
· Exposing SMTP, IMAP, POP3 services to 110% of their maximum load
· Flushing out the DB Table spaces to their maximum, proving the maximum, proving ability to recover/get back to a good place when the maximum limits have been exceeded
· Proving serviceability errors and warnings when thresholds are hit
2 Evaluation Strategy
The following section outlines the test environment and strategy to evaluate Domino 8.5.1
2.1 Test Environment
The IBM test environment contains the iSeries machine and 6 connecting clients as shown below:
The environment consists of an iSeries machine with two Domino partitions. Each partition server will host 2,500 registered users with 1,500 active users.
Transaction logging was enabled on the internal disk subsystem as Input Output on the iSeries is surprisingly low in comparison with other platforms.
The design task was run nightly as per default settings to upgrade the system templates.
The Updall task was set to run at default settings.
2.2 Evaluation Criteria
The performance of Domino 8.5.1 is evaluated under the following criteria:
- Server CPU: The overall CPU of the server will be monitored over the course of the test. The aim is for the server CPU not to go above 75% over the course of the test, allowing the server to function appropriately. It is acceptable for the CPU to occasionally spike at this level for a short period of time, but it must return to a lower level. High CPU results from the server being stressed due to processes running such as compact, fixup or replication or from user load or any other third party programs.
- Domino Processes CPU: The previous metric monitors the overall CPU of the server, however the CPU consumption of Domino specific processes will also be monitored individually. In this manner the CPU consumption of Domino specific processes may be evaluated.
- Server Memory: The server memory metric represents the amount of physical memory available on the server. If the available memory becomes low the server performance could be compromised.
- Server Disk I/O: The disk is a source of contention when a server is under load and performing a high number of read and write operations. The disk queue length is measured to determine if the disk Input/Output operations are resulting in a bottleneck for the system performance.
- Network I/O: These metrics monitor the network utilization to ensure the bandwidth consumption is acceptable and that the network is not overloaded.
- Response Times from the End-user Perspective: The server response times for user actions represent how long a single user must wait for a given transaction to complete. This metric captures the user experience of the application with the server. At times, response times will be longer when a server is under load. When response times increase over an extended period, or persist at high levels (e.g. when a database or view takes longer than 30 seconds to open), they indicate that performance indicators are being hit and detailed analysis must be performed to determine the source of the slowdown and seek remediation.
· Open Session Response Times: In addition to monitoring the individual action response times, the Open session response times will also be evaluated in order to ensure the server remains responsive over the course of the tests.
2.3 Tools
In order to simulate user activity and capture the evaluation metrics discussed in section 2.2 a number of tools must be used.
- Server.Load : The Server.Load tool is the IBM Lotus Domino load generation tool which can be used to measure and characterize various Lotus Domino server capacity and response metrics under load. The load is generated by running workloads that simulate the behavior of Lotus Domino client-to-server operations. The workloads enable simulating consistent, repeatable loads against the Domino server. Server.Load additionally captures action response times as discussed in section 2.2 which may be recorded and analyzed.
- Domino showstats data: The Domino showstats captures important server metrics, a Server.Load client driver may be used to execute the showstats console command at regular intervals for each server in the configuration and will provide Domino-specific data. The resulting data is logged in a text file and may be graphed for analysis.
- Open session: The Open session tool measures mail file request/response times. It will open a view of a mail database at a set time interval and record the response time in milliseconds. As a result, a server slow down may be identified by analyzing the resulting response times.
- System iNavigator’s Collection Services: This is used to graph the CPU Usage, Disk IOP Utilization and Lan Utilization during the 7 day run.
2.4 Evaluation Process
The Server.Load tool will be used to create load on the Domino server. In order to simulate realistic load on the Domino server a total of 6 client drivers running Server.Load will be used.
Both NRPC and HTTP users were active for 24 hours a day, 7 days a week for this test so the system is “stressed” more than for a typical working day alone. This also means the system will be performing its “housekeeping” activities with an active user load.
3 Scenario: Online Mode
The scenario evaluates the performance of Lotus Notes Clients in online mode. Online mode means that the user mail files are stored and maintained on the Domino server.
Every time a user performs an action the request is sent to the server and the mail file is modified and updated on the server side.
N85Mail Script (NRPC) |
Workload Actions | Action Count per hour per user current script | Action Count per 24 hour per user current script |
Refresh inbox | 4 | 96 |
Read Message | 20 | 480 |
Reply to all | 2 | 48 |
Send Message to one recipient | 4 | 96 |
Send Message to three recipient | 2 | 48 |
Create appointment | 4 | 96 |
Send Invitation | 4 | 96 |
Send RSVP | 4 | 96 |
Move to folder | 4 | 96 |
New Mail poll | 4 | 96 |
Delete two documents | 4 | 96 |
Total Messages sent | 16 | 384 |
Total Transactions | 52 | 1248 |
Table 1 shows the action workload of the built in N85Mail script with modifications to the attachment size. The script reflects the workload that is expected of a single user over the course of a day.
Message Distribution in N85 Mail Script |
Message size distribution | Percent of messages sent | Attachment size ( if any ) |
0 < size <= 1k | 5.9% | N/A |
1k < size <= 10k | 66% | N/A |
10k < size <= 100k | 25.0% | 50 KB |
100k < size <= 1mb | 2.8% | N/A |
1mb < size <= 10mb | .3% | 10 MB |
|
Table 2
The resulting mail distribution is shown in table 2.
N85DWA Script (HTTP) |
Workload Actions | Action Count per hour per user current script | Action Count per 24 hour per user current script |
Refresh inbox | 4 | 96 |
Read Message | 20 | 480 |
Reply to one message | 4 | 96 |
Send Message to one recipient | 4 | 96 |
Send Message to three recipient | 4 | 96 |
Create appointment | 4 | 96 |
Send Invitation | 4 | 96 |
Send RSVP | 4 | 96 |
Move to folder | 4 | 96 |
New Mail poll | 12 | 288 |
Delete two documents | 4 | 96 |
Total Messages sent | 20 | 480 |
Total Transactions | 68 | 1632 |
Table 3
Table 3 shows the action workload of the built in N85DWA script with modifications to the attachment size. The script reflects the workload that is expected of a single user over the course of a day.
Message Distribution in N85DWA Script |
Message size distribution | Percent of messages sent | Attachment size ( if any ) |
0 < size <= 1k | 7.8% | N/A |
1k < size <= 10k | 60% | N/A |
10k < size <= 100k | 30% | 50 KB |
100k < size <= 1mb | 2% | N/A |
1mb < size <= 10mb | .2% | 10 MB |
|
Table 4
The resulting mail distribution is shown in table 4.
4 Conclusion and Summary
The test results demonstrate that the IBM iSeries System configured as described in this report can support up to 1,500 concurrent, active Notes 8.5.1 users per Domino Server partition (3,000 in total) with an average response time well below 1 second.
The addition of other application workloads will affect the number of users supported as well as the response time. Achieving optimum performance in a customer environment is highly dependent upon selecting adequate processor power, memory and disk storage as well as balancing the configuration of that hardware and appropriately tuning the operating system and Domino software.
Appendix A: Overall Test Setup and Software Versions
Number of Client Systems
For the Notes 8.5.1 online mode test, 6 driver systems were used to generate Server.Load load. In addition another machine was used to run both the OpenSession tool and the Domino Showstats client.
The configuration used for the driver systems follows:
Driver machine specifications:
- Intel Pentium® 4, 2 CPUs, 2.4GHz with 1GB memory
- C: Partition (80GB - NTFS) - Microsoft Windows XP Professional SP2 and Notes 8.5.1 gold client
Server System
One iSeries 825 server with 6 x 1.1 GHz Processors, 16 GB of memory and 914GB of disk (provided by 30 disks).
Software Versions
Software versions used on the system under test were as follows:
- i5/OS V6R1M0 for iSeries
- Lotus Domino 8.5.1 Gold for iSeries
Software versions used on the client drivers machines were as follows:
- Microsoft Windows XP Professional SP2
- Lotus Notes 8.5.1 Gold and Domino Administrator 8.5.1 Gold client
Appendix B: System Configurations
System Under Test:
System | iSeries V5 system |
Processor | 6 x 1.1 GHz Processors |
Memory | 16 GB of memory |
Operating System | i5/OS V6R1M0 for iSeries |
Domino Server | Lotus Domino 8.5.1 Gold for iSeries (Enterprise Server) |
| |
Appendix C: Notes/Domino Parameters (NOTES.INI file)
Specific Notes.ini Settings for the two servers can be seen as follows:
NOTES.INI settings from Server 1
ServerTasks=Replica,Router,Update,AMgr,Adminp,Sched,CalConn,RnRMgr,COLSRV400,SMTP,HTTP,LDAP,POP3
CREATE_R85_DATABASES=1
EVENT_CORRELATION_POOL_SIZE=104857600
NOTES.INI settings from Server 2
ServerTasks=Replica,Router,Update,AMgr,Adminp,Sched,CalConn,RnRMgr,COLSRV400,SMTP,HTTP,LDAP,POP3
CREATE_R85_DATABASES=1
EVENT_CORRELATION_POOL_SIZE=104857600