Export (0) Print
Expand All

Baseline Performance for Outlook Web Access

 

Topic Last Modified: 2005-05-10

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.

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

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

  • Not applicable

Back-end server 1

Intel P4 Xeon 4 processors, 1.4 GHz

4 GB

  • 20 spindles of RAID0+1 for database volumes

  • 4 spindles of RAID0+1 for the transaction logs for each storage group

Back-end server 2

AMD Opteron 4 processors, 1.6 GHz

2 GB

  • 20 spindles of RAID0+1 for database volumes

  • 4 spindles of RAID0+1 for the transaction logs for each storage group

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

This scenario uses the same hardware configuration used in Outlook Web Access Scenario 1.

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.

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.

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.

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.

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.

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 usage and context switching is similar among the tests with approximately 40 percent CPU usage and 12,000 context switches.

Memory consumption is similar among all the tests. The SSL enabled tests use less memory in the Inetinfo process.

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 consumption is similar among all the tests and well within the requirements for a 100 Mbps network adapter.

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

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

  • Not applicable

Front-end server 2 (MAPI, RPC over HTTP)

AMD Athlon 2 processor 1.2 GHz

2 GB

  • Not applicable

Front-end server 3 (MAPI, Outlook Web Access)

Intel P2 Xeon 2 processors, 450 MHz

1 GB

  • Not applicable

Back-end server

Intel P4 Xeon MP 4 processors, 1.4 GHz (Hyper-Threading)

4 GB

  • 40 spindles of RAID0+1 for database volumes

  • 2 spindles of RAID0+1 for the transaction logs for each storage group

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.

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.

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.

 
Was this page helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft