IMAP Server
The Internet Message Access Protocol (IMAP) server, based on RFC 2060, permits a client email program to access remote message folders (called "mailboxes") as if they were local. IMAP's ability to access messages (both new and saved) from more than one computer has become more important as reliance on electronic messaging and use of multiple computers increase. The protocol includes operations for creating, deleting and renaming mailboxes; checking for new messages; permanently removing messages; setting and clearing flags; server-based parsing and searching; and selective fetching of message attributes, texts, and portions thereof for efficiency.TCP/IP level 420, with z/VM 4.2.0, now supports the IMAP server. This section summarizes the results of a performance evaluation of this support.
Methodology: An internal CMS tool was used to simulate user load against an IMAP mail server using custom scripts. The scripts were staggered by using a uniformly distributed random number between 100 and 500 seconds to distribute the load evenly over a one-hour period.
Each simulated client, after logging in, checks its inbox for new messages six times (once at the end of each random period). Each time the inbox is checked, the client downloads five message headers from the inbox, reads those five messages, and then deletes one message. After the sixth iteration, the simulated user logs out and sends a new message (through SMTP). Each instance of sending a request to the IMAP server and receiving a response is considered a transaction. More specifically, a transaction is defined as each request issued by the internal tool to the IMAP server. For example; LOGIN, list INBOX, SELECT, UID fetch are transactions or requests sent to the IMAP server. Each simulated user issues 59 transaction requests to the IMAP server during each measurement run.
All measurements were done on a 2064-109 in an LPAR with 2 dedicated processors. The LPAR had 1GB central storage and 2GB expanded storage. All clients, the IMAP server, SFS server, and TCPIP stack ran on the same LPAR. APAR PQ54859 was applied to the IMAP server because it contained a fix to thread priority that impacted the performance. SFS ran with 504 agents, ensuring that the number of SFS agents was always greater than the number of IMAP threads. Response times were captured by the internal tool and CP monitor data was captured once the workload had reached a steady-state. The CP monitor data was then reduced using VMPRF. Data for SFS and TCP/IP is also shown but the focus is on what we see the IMAP server doing.
Throughput and Response Time Results: The throughput and response time results are summarized in Figure 1 and Figure 2.
 |
 |
The graphs show that response times are good until about 2900 users, when response times begin to rise sharply and transactions per second drop. At 3000 users the IMAP server is either running or waiting on the CPU for almost 90% of the time. So the primary constraint is due to IMAP only being able to run on a single processor at a time.
Detailed Results: The following tables give further detail for each of the measurements. All of the fields were obtained from the workload driver or derived from the CP monitor data, except IMAP threads which was obtained from the IMAP administration command IMAPADM servername STATS. Following is an explanation for each field.
trans/sec (est) | Transactions per second was estimated from monitor data records which show message traffic from TCPIP to the IMAP server. This value was compared to the value reported by the internal tool to ensure reasonableness. This value was then divided by the elapsed time shown in the VMPRF report. |
Response time (driver) | The workload driver kept track of the time elapsed for each transaction request issued to the IMAP server and reported the average transaction time at the end of the run. |
Total CPU Utilization | This field was obtained from the SYSTEM_SUMMARY_BY_TIME VMPRF report that shows the average of both processors. |
IMAP CPU Utilization | This field is calculated from the IMAP entry in the USER_RESOURCE_UTILIZATION VMPRF report. |
IMAP tot CPU msec/trans | This field was calculated from two of the previous fields (IMAP CPU Utilization divided by transactions per second) to show the number of IMAP milliseconds of time to transaction ratio. |
IMAP virt CPU msec/trans | This field is calculated in the same manner as IMAP total CPU msec/trans, using virtual CPU seconds for the IMAP server. |
IMAP CP CPU msec/trans | This is the difference of total CPU msec/trans less virtual CPU msec/trans yielding the time spent in CP on IMAP's behalf. |
SFS CPU Utilization | This field is calculated in the same manner as IMAP CPU Utilization, using the SFS entry in the USER_RESOURCE_UTILIZATION VMPRF report. |
SFS tot CPU msec/trans | See IMAP tot CPU msec/trans. |
SFS virt CPU msec/trans | See IMAP virt CPU msec/trans. |
TCPIP CPU Utilization | See IMAP tot CPU Utilization. |
TCPIP tot CPU msec/trans | See IMAP tot CPU msec/trans. |
TCPIP virt CPU msec/trans | See IMAP virt CPU msec/trans. |
Number of IMAP threads | This number was obtained from the IMAP administration command IMAPADM, specifying the STATS option. |
SFS sec per filepool req | Total Time Per File Pool Request field in SFS_BY_TIME VMPRF report. |
SFS request per trans | Calculated by dividing FPR count from SFS_BY_TIME by Total Msgs from TCPIP to IMAP from USER_TO_USER_VMCOMM VMPRF report. |
Table 1. IMAP Measurement Results
IMAP Clients Run ID | 1500 I50030z3 | 2000 I50040z2 | 2500 I50050z3 | 2750 I50055z2 | 2900 I50058z1 | 3000 I50060ze |
|---|---|---|---|---|---|---|
trans/sec (est) Response time (driver) trans/sec/user Total CPU Utilization | 57.38 0.01 0.04 20.9 | 89.07 0.02 0.04 30.6 | 122.57 0.03 0.05 40.2 | 125.53 0.07 0.05 47.6 | 182.58 0.41 0.06 52.5 | 60.75 1.48 0.02 53.0 |
IMAP CPU Utilization IMAP tot CPU msec/trans IMAP virt CPU msec/trans IMAP CP CPU msec/trans Number of IMAP threads | 26.59 4.63 4.33 0.30 5 | 41.01 4.61 4.34 0.26 5 | 56.59 4.62 4.39 0.23 10 | 67.39 5.41 5.16 0.25 37 | 75.58 4.14 3.95 0.19 30 | 77.07 12.69 12.08 0.60 45 |
SFS CPU Utilization SFS tot CPU msec/trans SFS virt CPU msec/trans SFS CP CPU msec/trans SFS sec per filepool req SFS requests per trans | 2.22 0.39 0.22 0.17 0.001 1.75 | 2.83 0.32 0.19 0.13 0.001 1.42 | 3.41 0.28 0.17 0.11 0.001 1.22 | 3.89 0.31 0.18 0.13 0.001 1.31 | 4.25 0.23 0.14 0.09 0.001 0.96 | 4.47 0.74 0.46 0.27 0.000 2.82 |
TCPIP CPU Utilization TCPIP tot CPU msec/trans TCPIP virt CPU msec/trans TCPIP CP CPU msec/trans | 2.78 0.48 0.29 0.19 | 3.70 0.42 0.26 0.16 | 4.28 0.35 0.21 0.14 | 5.16 0.41 0.30 0.15 | 5.50 0.30 0.19 0.11 | 5.13 0.85 0.49 0.35 |
| Note: 2064-109; z/VM 4.2.0 with 64-bit CP; TCP/IP 420; IMAP with APAR PQ54859 | ||||||
SFS requests are mostly asynchronous and SFS response time is even for all measurements (even the 3000 user case). Therefore SFS is not a factor in the IMAP server response time.
Total CPU utilization shown includes activity in the IMAP clients as well as IMAP, TCPIP and SFS.
The IMAP server scales well to 2500 users. CPU msec/trans stays steady until after 2500 users. It increases slightly at 2750 users and begins to become unstable at 2900 users. By 3000 users the IMAP server cannot keep up with the requests coming in and the backlog affects the response time seen by the client dramatically.