cancel
Showing results for 
Search instead for 
Did you mean: 

EV EMA and Sizing spreadsheet question

KeirL
Level 6
Partner

Hi

I've recieved some figures from the EMA tool (I'm using version 3) and pluged these into the sizing tool. Generally very impressed with the whole tool etc but there is one question I'd like to clarify a bit.

So on the tool, and it appear on most tabs so I'll pick the 'ExchMbxSteadyState' tab for this question, there is a figure for "Throughput rate adjustment due to message size" which is in the last table (line 101) and has a figure that has been manually adjusted down from the benchmarked ingest rate due to the higher than 'average' message size.

That's all fine and I get the reason why the figure has been adjusted - but my specific question is:

Is there a particular process that suffers due to large message sizes? eg If it's the indexing then can I offload indexing to an index server group to increase the throughput? btw - if I set indexing to 0% this fugure doesn't change. If it's SIS then wouldn't it need to know how I plan to share (in store or in group) if I plan to share at all.

Just curious as to why it can drop so dramatically ( by 2/3rds in my case) and if I can do any configuration changes to minimise the impact. Apart from double the spec of the server...... :o)

kind regards

KL

1 ACCEPTED SOLUTION

Accepted Solutions

TonySterling
Moderator
Moderator
Partner    VIP    Accredited Certified

It is just the processing\storing of the items that is taking the time.  Nothing you can do but add CPU and Memory.  smiley

View solution in original post

7 REPLIES 7

TonySterling
Moderator
Moderator
Partner    VIP    Accredited Certified

Hey ya,

Off loading Indexing would help some but the primary thing is the amount of data you are trying to push through the Storage Services.  What is your average size of a mail?

Best,

 

KeirL
Level 6
Partner

Hi Tony

the ema is coming back with an average mailsize of 240KB (including attachments) with a 25% attachment ratio,average attachment size of 350KB with an average of 2.5 attachments per email  - (average size without attachment is only 25KB)

If offloading the indexes would help - is there anyway to get an understanding of how much it might help? Most of these attachements are text based so I increased the indexing size to 20% as I think there's a lot of indexable content to be addressed, but even if I set that figure to 0% (eg all pictures and nothing to index - except the very small message body) the throughput didn't change and is still down at 26,667 instrad of the benchmark of 60,000

cheers

TonySterling
Moderator
Moderator
Partner    VIP    Accredited Certified

I really don't think offloading indexing would help much with your scenario.  The decrease throughput is based on the larger message size. 

Can you share some more background?  How many Exchange servers?  Mailbox and Journaling or just Journaling?  What is the expected volume of mail per hour or day?

KeirL
Level 6
Partner

Thanks again - I really appreciate your thoughts on this.

So its an 8 node Exchange 2010 DAG with 4 active and 4 passive nodes hosting about 5500 mailboxes. I will be archiving both mailboxes and journals (no FSA or Sharepoint). The expected volumes is coming in at 55 emails per user to archive per day   - this is the average number of daily emails resident in the user's mailboxes after 3 months (eg the number that will meet the archiving policy per user for that night's archiving run). The sizes and attachment ratios are in my previous post.

There are 4 journal archives and collectively they are hitting about 1 million items a day with the core hours being from about 7am to 7pm.

This actually raises a  new question:

The sizing spreadsheet takes the number of messages through the journal a day eg 1 million and devides that the number of core hours I assign (12 hours in my case) so tells me I need to archive 1,000,000/12 = 83k items an hour. It then takes my 26,667 archiving rate (due to large message size) and tells me I need 83,000/26,667 = 3 EV servers. But as journal archiving is a 24/7 operation isn't it acceptable to allow a little lag whereby during the core hours more items will come into the journal mailboxes than I can archive out, but EV will catch up outside of these core hours when message flow is massively lower? Yes I need to make allowances for nightly backups but this is all done via NetApp snapshots so has very little time impact.

I think I should be sizing the number of journal servers based on the fact I can archive for at least 20Hrs a day and not just the 12 hours that messages are streaming into the journal mailboxes.

what do you think?

GertjanA
Moderator
Moderator
Partner    VIP    Accredited Certified

I believe that seeing the amount of mail in the Journal Mailboxes daily, you need to have at least 1 dedicated Journal Archiving server (no mailbox archiving on it). If it is possible to use multiple Journal Mailboxes, then it might be wise to seperate journaling, and use multiple tasks to target those mailboxes.

I've been in an environment recently where there were 1.8 million messages coming into Journal mailboxes daily. What you will see is what you ask, being that the items in the Journal mailbox will go up during the day, (I've seen numbers like 80000 to 100000 around 18:00), but the journalmailboxes will be empty in the morning.

 

Regards. Gertjan

KeirL
Level 6
Partner

Great - thanks Gertjan

I will have dedicated journal archiving server - in fact I was going for 2 dedicated EV journal archiving servers based on the fact that, if my large message size means my throughput is only circa 26k per hour but I can archive for at least 20hrs per day then I can do over 550k items a day on each EV server which will be over 1 million items a day. Sure, items will build up during the day but it will catch up before the start of business the next day - which I think is fine.

my original query was why do large message sizes half the throughput of an EV server (is it indexing, or SIS, or what) but I guess it's just 'processing in general' so nothing that can be done to ease that pain other than adding more compute power. - which is fine and I can accept that as an answer..

 

TonySterling
Moderator
Moderator
Partner    VIP    Accredited Certified

It is just the processing\storing of the items that is taking the time.  Nothing you can do but add CPU and Memory.  smiley