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

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics