Effect of increased IO on MAPI requests
Hi All
This is just a theoritical question really....I have been looking at introducing Blackberry Server to my Exchange environment and heard that it hits the IO of the server pretty bad (presumably due to MAPI calls). The BES and Exchange servers will actually
be hosted on different boxes in this scenario.
I had some further questions on this I was hoping a Storage/Exchange guru could answer for me. This will be the last question I asked on this topic I promise :)
i) I/O: I understand that to counter the increase in IO, we should have more disks...however, what is the effect if we don't on Exchange? Will requests just get queued and users see "Exchange is too busy to handle your request" type notifications in Outlook?
ii) Will increase I/O that is not handled well lead to increased RPC Latency?
iii) What actually is the definition of RPC Latency? Is it simply the time taken to carry out RPC requests?
iv) Would people say that MAPI is a disk-intensive "protocol"?
v) Let's say I restarted BES and it needs to rescan all other BES users' mailboxes. This would lead to a massive increase in MAPI requests on the Exchange server, correct? How would Exchange deal with this?
vi) Same situation (BES services restarted), what would be the resource that took the highest hit? I/O?
June 8th, 2010 7:17pm
On Tue, 8 Jun 2010 16:17:11 +0000, Yoshi66 wrote:
>
>
>Hi All
>
>This is just a theoritical question really....I have been looking at introducing Blackberry Server to my Exchange environment and heard that it hits the IO of the server pretty bad (presumably due to MAPI calls). The BES and Exchange servers will actually
be hosted on different boxes in this scenario.
>
>I had some further questions on this I was hoping a Storage/Exchange guru could answer for me. This will be the last question I asked on this topic I promise :)
>
>i) I/O: I understand that to counter the increase in IO, we should have more disks...however, what is the effect if we don't on Exchange? Will requests just get queued and users see "Exchange is too busy to handle your request" type notifications in Outlook?
That's one of the things that will happen.
>ii) Will increase I/O that is not handled well lead to increased RPC Latency?
Yes -- if you measure the latency from the time the RPC is issued
until the time it's answered. The actual amount of time the RPC takes
ot execute may not be dramatically different, but that depends on how
much I/O the individual RPC generates.
>iii) What actually is the definition of RPC Latency? Is it simply the time taken to carry out RPC requests?
Measured from the client, it's the time elapsed between issuing the
RPC and getting the result.
>iv) Would people say that MAPI is a disk-intensive "protocol"?
MAPI is an abstraction layer that presents a uniform set of functions
to client software. MAPI then "converts" the common function into the
specific actions necessary to accomplich the tasl. Those funtions will
differ based on what you're connected to and how you're connected to
it. MAPI doesn't do any I/O at all, it's all software.
>v) Let's say I restarted BES and it needs to rescan all other BES users' mailboxes. This would lead to a massive increase in MAPI requests on the Exchange server, correct? How would Exchange deal with this?
I don't know how BES works. Sorry.
>vi) Same situation (BES services restarted), what would be the resource that took the highest hit? I/O?
---
Rich Matheisen
MCSE+I, Exchange MVP
--- Rich Matheisen MCSE+I, Exchange MVP
Free Windows Admin Tool Kit Click here and download it now
June 9th, 2010 4:30am
Disk I/O requirements have changed dramatically (for the better) from Exchange 2003 to 2007 and again to 2010 ... so it really depends what version you are talking about. Amount of physical RAM will also make a difference.
http://msexchangeteam.com/archive/2010/03/29/454443.aspx
http://msexchangeteam.com/archive/2007/01/15/432207.aspx
http://docs.blackberry.com/en/admin/deliverables/8864/BlackBerry_Enterprise_Server_for_Microsoft_Exchange-5.0-US.pdf
June 9th, 2010 7:50am