• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 918
  • Last Modified:

Going to Office 365 looking at metro ethernet is there a calculation to help determine bandwidth needed

We are 150 users and are going from on premise office and Exchange to Office 365.
We have 5 branch offices that come to corporate for internet, but we are moving our datacenter offsite to a co-location and will be giving all sites including corporate internet access from that facility.  Is there a calculator for determining bandwidth for Office 365  as they are proposing 5 Mbps Metro Ethernet but I'm not sure how to properly size it and want to make sure the network doesn't cause poor user experience
  • 6
  • 6
1 Solution
bergquistcompanyAuthor Commented:
Excellent article so if I understand this right I change the following:
Network bytes/sec = (100 heavy users × (5,200 KB/user ÷ day)) ÷ (8 hr/day × 3600 sec/hr) = 18.5 KB/sec

I'm unclear what day is that you are dividing 5200 from as I've tried 5 and 7 but don't get 18.5
His calculation is out, it should be 18.05 not 18.5.

However, I would take those numbers with a pinch of salt, in my experience, most people receive and send more than his "very heavy", they also send and receive attachments. Frequently people will send attachments internally, creating  large "spike" in usage.

You will also see spikes first thing in the morning as people receive the emails that were sent to them after they closed Outlook, and as they send emails at the end of the day.

I would instead calculate bandwidth based on

a/ the time it would take to send your largest allowed attachment, increase your bandwidth till this becomes an acceptable time (I use 5 seconds) , then double your bandwidth.

b/ the time it would take to resync a maibox when somebody gets a new computer.

The time it takes to receive doesn't have much effect on user perception, however the time an email takes to send does as they can see it in their outbox, and if they close Outlook at the end of the day before it has sent, it won't send before they start outlook the following morning...

Latency between the office and Office 365 also has a large impact on the time it takes to send a large message, all those TCP packets, each one needing an ack...

Users will notice a reduction in perceived performance compare to an onsite correctly specified and managed server, your offsite users will probably not notice as much.

Several years ago, after I had been instructed to look at moving to hosted Exchange for a client, for a test, I put their primary Exchange 2007 CAS server on a 100mb port instead of a gigabit port, I did the change at 7am before people started work, there was a flood of support tickets opened when people came in complaining that email was slow. Granted this was for ~400 people and their usage was significantly higher than the "very heavy" user in the article, but hopefully you can see the issue, the port was changed back to gigabit at 10am and the flood went away.... They ended up staying with onsite Exchange.
Creating Active Directory Users from a Text File

If your organization has a need to mass-create AD user accounts, watch this video to see how its done without the need for scripting or other unnecessary complexities.

bergquistcompanyAuthor Commented:
Thank you so much for all of the detailed information.  I can clearly understand the impact of sending, but regarding a) how can you really test this.  All branch offices right now have their own Exchange server so it remains onsite.  I'm concerned with how it will change when sending to the person next to you over the internet.

When you say resync (b) is that complete cache and if tested internally what would I realistically multiply that by for the internet?

I'm looking at about 10000 messages sent a day with an average size of 140kb giving heavy use at 140000 * 600 users in the company - traffic per day at 84000000 in 8 hours per shift (operating 24 hours a day) divided by 28800 seconds per user per day = 2916KB doubled at 58MB pipe?
Yes, its the way that an internal email uses your Internet bandwidth twice...

I would suggest doing some basic tests with gmail/hotmail etc to establish what performance you have on your existing connections, you can then extrapolate to other bandwidths, latency also has an impact on time.

As you have onsite Exchange servers at each site, you could do some simple bandwidth monitoring using a tool such as PRTG to look at the current usage.
bergquistcompanyAuthor Commented:
Excellent I will try that but found this and had a question

if network bytes/sec =900 kB/sec

I'm unclear hwo they get to

network bits/sec=7.2Mb/sec

Where does the 7.2 come from?

b is bits
B is bytes

there are 8 bits in a byte

so 900KB/s = 7.2Mb/s...
bergquistcompanyAuthor Commented:
so if I do this right I have 618 users and according to our spam filter we send/receive 10,000 messages a day at 152kb average in size.  Thus I am doing 10000x152 to get my KB sent a day =1520000 x 618 users for the top total and dividing that by 8*3600 or 28800 to get 32616 or 260MB.

Doubling for peak I'd need to support 512MB/sec?  Does that seem right?  

That's just your external email, you also need to factor internal email...

You appear to be mixing B (bytes) and b (bits) in your calculations. As bandwidth is always b, I tend to keep the calculation in b

You have also moved from 150 users to 618, however as you have a daily total, the number of users isn't needed.

If your average size is 152kb and you send/receive 10k emails, then the calculation works like this.

152* 10000 = 152,000 kb in 24 hours

 (24*60*60) =- 86400 seconds per day

152000 / 86400 = 17.6kb /second over 24 hours, but you are only using 8 hours, so as 24 / 8 = 3,  you would need to multiply by 3

17.6 * 3 = 52.8 kb/s

If, as I suspect your spam filter is counting in B not b, as "files" are usually counted in bytes, not bits, you would then multiply by 8, so 422.4 kb/second of constant traffic, double it and you'll get a ~1mb connection

This means that a person that sends a 20mB email (large spreadsheet, pdf file etc) will have to wait at least (20*8) = 160mb and as the connection is 1mb /seconds that's 160 seconds to send the email, but you have a "constant" ~500 kb /second of traffic so 160 seconds, becomes 320 seconds = over 5 minutes... and this is excluding any other traffic going over the link, web browsing, AD replication, file transfers etc.

I would as I suggested previously, work on how long it would take to send a 20mB email

presuming no other overheads and no other traffic on the link....

to get to 30 seconds would be ~5.5mb /second, double it to cover for two people and you get 11 mb /second
to get to 10 seconds would be ~16.5mb /second, double it to cover for two people and you get to 33mb /second

All of the hosted email providers will play down the bandwidth requirement, as the costs for the bandwidth are part of the TCO of using a hosted service

Granted I don't know your exact situation, but I would suggest that you ran a "limited trial"  with the ability to move back to on premise if performance is not acceptable.
bergquistcompanyAuthor Commented:
All of the hosted email providers will play down the bandwidth requirement, as the costs for the bandwidth are part of the TCO of using a hosted service....for this reason alone I am trying to get some initial calculations as you mention it can make/break things.

I will definitely take that advice on the "limited trial"

I am in the process of running your suggestions on sending a 20mb email and like the calulations.  Thus 33mb is realistic ha and that is NOT including internal and normal internet traffic so we could really be looking at 50mb would not be out of the question.
bergquistcompanyAuthor Commented:
Fabulous information
thanks, and I hope you trialling goes well :-)
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Keep up with what's happening at Experts Exchange!

Sign up to receive Decoded, a new monthly digest with product updates, feature release info, continuing education opportunities, and more.

  • 6
  • 6
Tackle projects and never again get stuck behind a technical roadblock.
Join Now