Baseline Performance for Outlook Web Access
This section provides baseline performance data on Outlook Web Access. Outlook Web Access is a Web interface that uses HTTP to access an Exchange server. With any Web browser, you can access most of the feature that are available to a client using Outlook. This section describes the following scenarios:
Scenario 1 Compares 10,000 Outlook Web Access users on the front-end server with similar mail flow on two different configurations: Exchange Server 2003 and Windows 2000, and Exchange Server 2003 and Windows Server 2003.
Scenario 2 Compares the performance when additional features are enabled while keeping the mail flow constant.
Scenario 3 Compares the performance when additional features are enabled while under various loads, using LoadSim.
Scenario 1
This scenario compares 10,000 Outlook Web Access users on the front-end server with similar mail flow on two different configurations: Exchange Server 2003 and Windows 2000, and Exchange Server 2003 and Windows Server 2003. The following configuration is used in this scenario:
There were four storage groups with three private mailbox stores in each storage group.
Clients send messages with an average size of 20 KB.
Each user's Inbox is populated with 31 IMAP4 messages before the test begins.
Transport traffic occurs as each user sends several e-mail messages to the Internet.
Each user connection lasts approximately 10 minutes.
The following tabe shows the actions performed by each user.
User test script
| Action | Times performed |
|---|---|
Log on |
1 |
Check mail |
2 |
Send messages |
2 |
Recipients of message sent |
1 |
Receive messages |
4 |
Read messages |
4 |
Move messages |
1 |
Delete messages |
1 |
Hardware
The following tabe shows the specifications of the three servers used in this scenario.
Outlook Web Access scenario 1 hardware
| Server type | Processor type | RAM | Storage |
|---|---|---|---|
Front-end server |
Intel P4 Xeon 2 processors, 2.6 GHz (Hyper-Threading) |
1 GB |
|
Back-end server 1 |
Intel P4 Xeon 4 processors, 1.4 GHz |
4 GB |
|
Back-end server 2 |
AMD Opteron 4 processors, 1.6 GHz |
2 GB |
|
Outlook Web Access Front-End Server
Client access to Outlook Web Access is provided through HTTP. The following table gives an overview of processor usage, context switches each second, network traffic, and memory usage on the front-end server with both Windows 2000 and Windows Server 2003.
Outlook Web Access front-end server comparison
| Front-end server | Exchange Server 2003 Windows 2000 | Exchange Server 2003 Windows Server 2003 |
|---|---|---|
Network Usage (in Kbps) |
4,679 |
6,313 |
Inetinfo Private Bytes |
518 MB |
38 MB |
W3WP Private Bytes |
Not applicable |
79 MB |
Available Mbytes |
276 MB |
484 MB |
% Processor Time |
52% |
21% |
Context Switches/sec |
11,795 |
13,791 |
Web Bytes Total/sec |
2,720 KB |
3,706 KB |
Web ISAPI Extension Requests/sec |
98 |
135 |
For more information about the performance counters used in this scenario, see Performance Counter Definitions.
Processor
In this scenario, Outlook Web Access uses significantly less CPU on the front-end server when running on Windows Server 2003. Context switching is stable and fairly low for 10,000 users.
Memory
The IIS Worker process (W3WP) in Windows Server 2003 is more memory-efficient than Internet Information Services (IIS) in Windows 2000 at servicing Outlook Web Access requests. In this scenario, Exchange Server 2003 running on Windows 2000 Server consumes 756 MB of RAM, and the server running Windows Server 2003 consumes only 540 MB. The core Inetinfo process in Windows Server 2003 pushes most of the work onto the W3WP process. The store process on both front-end servers consumed a negligible amount of RAM.
Disk Usage
For information about disk usage for a dedicated Outlook Web Access front-end server, see "Disk Usage" in "POP3 Front-End Server" later in this topic.
Network Usage
For more information about network usage for a dedicated Outlook Web Access front-end server, see "Network Usage" in "POP3 Front-End Server" in Baseline Performance for POP3.
Outlook Web Access Back-End Server
The following table shows the results produced by the Outlook Web Access back-end server.
Outlook Web Access back-end server comparison
| Back-end server | Exchange 2003 Windows 2000 | Exchange 2003 Windows Server 2003 |
|---|---|---|
Database Cache Size |
896 MB |
896 MB |
Available Mbytes |
409 MB |
93 MB |
Local Delivery Rate |
7 |
6 |
Network Usage (in Kbps) |
4,705 |
6,313 |
Disk Bytes/Sec |
14,739 KB |
15,365 KB |
DB Disk Transfers/sec |
1,959 |
1,723 |
Inetinfo Private Bytes |
83 MB |
124 MB |
Store Virtual Bytes |
1,788 MB |
1,764 MB |
% Processor Time |
27% |
38% |
Context Switches/sec |
15,769 |
14,363 |
Web ISAPI Extension Requests/sec |
59 |
81 |
For more information about the performance counters used in this scenario, see Performance Counter Definitions.
Processor
Although CPU usage is reduced on the front-end server under Windows Server 2003, the back-end server shows increased CPU usage. Higher throughput on the Windows Server 2003 test consumes more CPU but the cost per operation is similar in both tests.
Memory
The four-processor Outlook Web Access back-end servers require at least 500 MB of RAM. During most of the four-processor scenarios described in this topic, the Store.exe process consumed more than 1 GB of RAM. Exchange Server 2003 uses a maximum of 3 GB of memory. To increase performance, increase memory up to 3 GB to reduce the paging to disk.
Disk Usage
When using a back-end server dedicated to Outlook Web Access clients, put each storage group's database files on a dedicated RAID0+1 array and use cache-backed controllers.
Network Usage
A 100 megabits per second (Mbps), full duplex, network connection is sufficient for all Outlook Web Access mailbox server applications. The Outlook Web Access tests conducted to support this guide do not exceed 7 Mbps network usage even under the most severe of test conditions. This level is well below the network saturation point of a 100-Mbps, full duplex network connection.
Scenario 2
This scenario compares the performance of additional Outlook Web Access features to the baseline Outlook Web Access test (Scenario 1). In this scenario, the following features are enabled:
Spelling check The Outlook Web Access baseline test is modified to check the spelling on every send, reply, and forward action to simulate a user using the spelling checker feature on sent messages.
SSL The Outlook Web Access baseline test is modified to use SSL encryption providing the security and an example of an Outlook Web Access SSL baseline test.
**Gzip compression **The Outlook Web Access SSL baseline test is modified to use gzip compression, reducing the size of the files sent over the wire.
S/MIME The Outlook Web Access SSL baseline test is modified to use Secure/Multipurpose Internet Mail Extensions (S/MIME) to encode every message sent, replied to, or forwarded.
Additionally, the following configuration is used in this scenario:
There are four storage groups with three private mailbox stores in each storage group.
2,000 Outlook Web Access users are used with 3.5 messages per second sent through SMTP inbound from the Internet.
Clients sent messages with an average size of 20 KB.
Each user's Inbox is populated with 31 IMAP4 messages before the test begins.
Transport traffic occurs as each user sends several e-mail messages to the Internet.
Each user connection lasts approximately 10 minutes.
The table in Scenario 1 shows the actions performed by each user in Scenario 2.
Hardware
This scenario uses the same hardware configuration used in Outlook Web Access Scenario 1.
Outlook Web Access Features - Front-End Server
Based on the user action listed in Scenario 1, the following data was observed.
Outlook Web Access front-end feature comparison
| Front-end server | Outlook Web Access baseline | Spelling checker | SSL | SSL gzip | SSL S/MIME |
|---|---|---|---|---|---|
Inetinfo Private Bytes |
36 MB |
36 MB |
29 MB |
29 MB |
29 MB |
Lsass Private Bytes |
50 MB |
58 MB |
211 MB |
212 MB |
222 MB |
Available MB |
517 |
484 |
335 |
338 |
289 |
% Processor Time |
12% |
23% |
27% |
29% |
33% |
Context Switches/sec |
3,303 |
3,685 |
3,462 |
3,461 |
3,794 |
Web Bytes Total/Sec |
332 KB |
494 KB |
377 KB |
384 KB |
508 KB |
Web ISAPI Extension Requests/sec |
34 |
46 |
34 |
35 |
45 |
For more information about the performance counters used in this scenario, see Performance Counter Definitions.
Processor
When the spelling checker is enabled, processor usage from the Outlook Web Access baseline almost doubles. The spelling checker is CPU intensive on the front-end server, and it can be manually or automatically enabled on every sent message. SSL uses 125 percent more CPU than the Outlook Web Access baseline. Enabling gzip compression increases CPU usage by 7 percent over the SSL baseline. Enabling S/MIME was the most CPU intensive, increasing CPU usage 22 percent over the SSL baseline. Context switches are low and similar among all the tests.
Memory
All tests show similar memory consumption. The SSL enabled tests show a decrease in available megabytes because the Lsass process consumes more memory. The Lsass process handles the credential and encryption of an SSL connection.
Disk Usage
An Outlook Web Access front-end server rarely uses its hard disk. For information about disk usage for a dedicated Outlook Web Access front-end server, see "Disk Usage" in "POP3 Front-End Server" in Baseline Performance for POP3.
Network Usage
All tests show similar network consumption. The spelling checker consumes 5 percent more network consumption on the front-end server because of the additional action of having to send the message to the front-end server to check spelling before finally sending the message for delivery. S/MIME is the notable exception with 27 percent more network consumption on the front-end server.
Outlook Web Access Features - Back-End Server
Most of the features tested affect the front-end server and not the back-end server.
Outlook Web Access back-end feature comparison
| Back-end mailbox server | Outlook Web Access | Spelling checker | SSL | SSL GZIP | SSL S/MIME |
|---|---|---|---|---|---|
Local Delivery Rate |
24 |
22 |
23 |
23 |
8 |
DB Disk Transfers/sec |
935 |
745 |
1,021 |
1,031 |
711 |
Network Usage (in Kbps) |
687 |
723 |
675 |
695 |
876 |
Inetinfo Private Bytes |
120 MB |
107 MB |
72 MB |
75 MB |
112 MB |
% Processor Time |
40% |
41% |
42% |
40% |
37% |
Context Switches/sec |
11,842 |
12,486 |
11,878 |
11,997 |
10,931 |
Web Bytes Total/sec |
271 KB |
312 KB |
275 KB |
291 KB |
400 KB |
Web ISAPI Extension Requests/sec |
34 |
41 |
34 |
35 |
45 |
For more information about the performance counters used in this scenario, see Performance Counter Definitions.
Processor
Processor usage and context switching is similar among the tests with approximately 40 percent CPU usage and 12,000 context switches.
Memory
Memory consumption is similar among all the tests. The SSL enabled tests use less memory in the Inetinfo process.
Disk Usage
An Outlook Web Access back-end server is very disk intensive. Use RAID0+1 for the database volumes and at least RAID1 for each transaction log in a storage group.
Network Usage
Network consumption is similar among all the tests and well within the requirements for a 100 Mbps network adapter.
Scenario 3
This scenario compares the performance when additional features are enabled under various MAPI user loads. In this scenario, 8,000 MAPI users are used with 3.5 messages a second sent through SMTP inbound from the Internet. The following configurations are tested:
MAPI baseline In this baseline test, 8,000 MAPI users directly access the back-end server and 3.5 messages are sent to the back-end server each second through SMTP inbound from the Internet.
MAPI, Exchange ActiveSync, and AUTD In this baseline test, 8,000 MAPI users directly access the back-end server and 3.5 messages are sent to the back-end server each second through SMTP inbound from the Internet. Two thousand, four hundred out of the 8,000 users use Exchange ActiveSync to synchronize their mobile devices with their mailboxes through the front-end server. Half of the Exchange ActiveSync users (1,200) have Always Up-To-Date (AUTD) set up for notifications. Each Exchange ActiveSync connection lasts approximately 3 minutes. Table 2.16 shows the actions each user performs.
RPC over HTTP This baseline test is routed through a front-end RPC proxy server.
MAPI and Outlook Web Access In this baseline test, 8,000 MAPI users directly access the back-end server and 3.5 messages are sent to the back-end server each second through SMTP inbound from the Internet. Five hundred Outlook Web Access users access their mailboxes through the front-end server. Each user connection lasted approximately 10 minutes, and each user performed the same actions described in Scenario 1.
The average client message size is 20 KB. Each user's Inbox is populated with approximately 31 IMAP4 messages before the test begins. Transport traffic occurs as each user sends several e-mail messages to the Internet.
Exchange ActiveSync user test script
| Action | Times performed |
|---|---|
GETHIERARCHY |
2 |
sync calendar |
5 |
sync contacts |
5 |
sync inbox |
2 |
getestimate calendar |
1 |
getestimate contacts |
1 |
getestimate inbox |
1 |
addmailrecipient |
0.6 |
sendmail |
1 |
syncadd contacts |
1 |
syncchange FOLDER("contacts").rnd |
2 |
syncdel FOLDER("contacts").rnd |
2 |
syncadd calendar |
1 |
Hardware
The following table shows the specifications of the four servers used in this scenario.
Outlook Web Access scenario 3 hardware configuration
| Server type | Processor type | RAM | Storage |
|---|---|---|---|
Front-end server 1 (MAPI, AUTD, Exchange ActiveSync) |
Intel P4 Xeon 2 processors, 2.6 GHz |
1 GB |
|
Front-end server 2 (MAPI, RPC over HTTP) |
AMD Athlon 2 processor 1.2 GHz |
2 GB |
|
Front-end server 3 (MAPI, Outlook Web Access) |
Intel P2 Xeon 2 processors, 450 MHz |
1 GB |
|
Back-end server |
Intel P4 Xeon MP 4 processors, 1.4 GHz (Hyper-Threading) |
4 GB |
|
Outlook Web Access Features Using MAPI - Front-End Server
The following table shows the performance of the three front-end servers under similar MAPI loads.
Outlook Web Access features using MAPI - front-end
| Front-end server 1 (MAPI, Exchange ActiveSync, AUTD) | Front-end server 2 (RPC over HTTP) | Front-end server 3 (MAPI, Outlook Web Access) | |
|---|---|---|---|
% Processor Time |
3% |
23% |
2% |
Context Switches/sec |
610 |
10,447 |
776 |
Web Bytes Total/sec |
6 KB |
253 KB |
123 KB |
Web ISAPI Extension Requests/sec |
4 |
61 |
3 |
For more information about the performance counters used in this scenario, see Performance Counter Definitions.
When you use a front-end server for RPC over HTTP proxy server, it consumes 23 percent of the two-processor 1.2-GHz server for 8,000 users with 10,000 context switches. The Outlook Web Access and ActiveSync stress is minimal on the front-end server. Memory and disk consumption is minimal and the network usage is 2 MB, well within the recommended 100-Mbps network adapter.
Outlook Web Access Features Using MAPI - Back-End Server
The following table shows the performance of the back-end server when specific Outlook Web Access features are enabled.
Outlook Web Access features using MAPI - back-end
| MAPI baseline | RPC over HTTP | MAPI and Outlook Web Access | MAPI, ActiveSync, and AUTD | |
|---|---|---|---|---|
Database Cache Size |
896 |
896 |
896 |
896 |
Log Writes/sec |
265 |
270 |
229 |
220 |
DB Disk Transfers/sec |
1,609 |
1,494 |
1,767 |
1,530 |
Disk Bytes/sec |
18.7 MB |
16.9 MB |
20.5 MB |
18.6 MB |
Local Delivery Rate |
26 |
25 |
26 |
22 |
RPC Operations/sec |
1,208 |
1,136 |
1,226 |
1,188 |
RPC Requests |
9 |
6 |
22 |
7 |
Network Usage (in Kbps) |
2,452 |
2,031 |
2,237 |
2,008 |
Inetinfo Private Bytes |
190 |
51 |
187 |
45 |
Store Virtual Bytes |
2,127 |
2,063 |
2,104 |
2,124 |
% Processor Time |
50 |
44 |
73 |
91 |
Context Switches/sec |
13,875 |
13,292 |
18,824 |
12,365 |
Web Bytes Total/Sec |
Not applicable |
Not applicable |
109 KB |
108 KB |
SMTP Messages Del/Sec |
7.6 |
7.6 |
8 |
7 |
Web ISAPI Extension Requests/sec |
Not applicable |
Not applicable |
3 |
17 |
For more information about the performance counters used in this scenario, see Performance Counter Definitions.
Based on this test, the following conclusions were drawn:
MAPI, Exchange ActiveSync, and AUTD versus MAPI
Four AUTD and Exchange ActiveSync notifications are sent per second.
On the back-end server, Exchange ActiveSync and AUTD notifications push the CPU usage over 90 percent to service the Exchange ActiveSync feature. The load on the front-end server is negligible.
RPC over HTTP versus MAPI
- When MAPI traffic is routed through a front-end proxy server, 8,000 MAPI users consume 23 percent of the front-end processor. The back-end server load is similar to the MAPI baseline test.
MAPI and Outlook Web Access versus MAPI
- With both Outlook Web Access and MAPI running, server CPU usage increases 23 percent in the back-end server. Context switching increases at a similar rate.
Outlook Web Access Scalability Guidelines
When you design an Outlook Web Access server, consider the following guidelines:
Outlook Web Access scales well on four-processor servers.
Use a ratio of one front-end server to four back-end servers.
Outlook Web Access requires 30 KB of RAM per active connection.
Outlook Web Access uses virtually no disk resources, unless the front-end server is paging or HTTP-DAV protocol logging is turned on.
Outlook Web Access requires a second 100-Mbps network adapter if it is servicing more than 5,000 connections.
Use Network Load Balancing to load balance an Outlook Web Access front-end server.
Outlook Web Access SSL connections require up to three times more processing power and 60 percent more memory on their front-end server.