So how much bandwidth is required for a typical XenMobile user? More specifically, how much bandwidth does each Android or iOS device consume when running WorxMail? Great question! That’s precisely what I’ll attempt to answer in this article…and “it depends” isn’t good enough when you’re trying to size WAN links or buy NetScaler boxes for a future XenMobile Enterprise deployment (NOTE: NetScaler is not typically going to be the bottleneck from a network throughput perspective – more often than not, the upstream pipe(s) will be your bottleneck since most XenMobile users will be coming in externally). But I’ll give you some real numbers at the end of this article and slap a disclaimer on it like a good Consultant. 😉
Before I just tell you the answer(s), I wanted to spend a brief moment talking about the methods I used to get these numbers. They come from 3 key sources:
- Our largest real-world XenMobile deployment to date
- The Citrix Engineering QA/Test team
- My personal use of the product over the last year+
A bit more background on each of these…our largest XME deployment to date is actually all iOS devices at this point, and it’s WorxMail (via STA) and one other custom-wrapped app. So no Android or WorxWeb in the mix there (yet). And it’s based on the 8.7 MR1 release. We analyzed the bandwidth from the endpoint/device side as well as the NetScaler side.
Our QA/Test team has been doing all sorts of testing with Android and iOS over the last 6 months in particular on the 8.6, 8.7 and 9.0 releases. They’ve been testing WorxMail with STA and mVPN. And they’ve been testing WorxWeb as well.
Lastly, I’ve been using WorxMail and WorxWeb on my personal Android Galaxy S3 device for the last year and a half (since we had a product really). And I’ve been using pre-release builds of the 9.0 version of WM for the last 2 months. It should also be noted that I use WM as my primary email client as opposed to Touchdown or the native Android email client. I sync both my Inbox and Sent folders via “Push” with a week’s worth of data (non-default settings I might add). I’ve been using free apps from the Play store such as RadioOpt’s “Traffic Monitor” to analyze bandwidth usage of specific apps.
Of course, there are some variables and your mileage will absolutely vary. Just like how many users you can get on a XA box or how many VMs you can get on a XenServer host. Or how much bandwidth a typical XA user consumes. So before I present the numbers, here are a few of the key variables that might affect the numbers:
- iOS vs. Android (we have slightly different WorxMail sync algorithms between the platforms that affect not only bandwidth, but battery life)
- STA vs. mVPN (you should be using STA with WorxMail, but mVPN will consume more bandwidth if you do decide to use it!)
- Release/Version (you will get slightly different results if you’re using the older 8.7 based Worx apps versus the newer 9.0 based Worx apps)
- Network Conditions (you might get slightly different results on WiFi versus 3G versus 4G LTE)
- Apps (WorxMail has a very different bandwidth usage and traffic “profile” than WorxWeb…and these are only two of the Worx apps, and you can obviously wrap a slew of other apps if you’d like as well – every app will consume different amounts of bandwidth)
- FTU vs. Active or Steady-State (when you first set up WorxMail in particular and sync email messages, you’ll consume a lot more bandwidth during that First Time Use (FTU) process/setup…as opposed to when you use the app day to day in the “steady state”)
And there are more variables as you can imagine such as how much email you get, which folders you sync, how often you sync, how much you use the app in the foreground, if you download and view attachments on the mobile device, etc. And as you can see, I’m really concentrating on WorxMail in this article since that is the #1 app we’re deploying these days via XenMobile.
Even though there are a ton of variables and I pulled data from 3 different sources, including one real-world customer deployment…the results are surprisingly similar. Here are the average bandwidth numbers per device for WorxMail and Worx Home:
- WorxMail FTU: 40-50 kbps (65% download vs. upload)
- WorxMail Steady-State (includes active and idle/background usage): 5-10 kbps (60% download)
- Worx Home FTU: 5 kbps (90% download vs. upload)
- Worx Home Steady-State: <1 kbps (70% download)
While I didn’t include numbers for WorxWeb or ShareFile above, a few quick comments – WorxWeb and ShareFile are much more intensive during actual usage as you can imagine (downloading images or attachments, streaming videos, etc.), but it’s not something you use all the time (at least not for me, and not nearly as much as WorxMail). But it’s more like ~100k per device when active and less than 1k when inactive, which is about 95-99% of the time. WorxMail, on the other hand, I seem to use actively much more throughout the day – so it’s only inactive say 60-65% of the time compared to 95-99%. Very different traffic profiles and that needs to be taken into consideration when sizing WorxWeb and/or ShareFile.
I was pleasantly surprised with how little bandwidth each device consumes when using Worx apps. About a year ago we were internally saying anywhere from 100k to 500k per device in the steady state. I’m glad we were being conservative (and way off)! Because it’s more like 5-10k per device. I actually found that my personal Android 4.4 device consumes about 2k per day when I’m not traveling…and closer to 7k per day when I’m on the road. And our internal QA/Test team is using 14k per device for a “highly active” WH+WM+WW user. So when you put it all together, it’s only about 5-10k per device with WM or 10-20k per device with all the Worx apps. If anything changes that significantly changes these numbers or we do more testing internally or at a customer site, I’ll make sure to update this article. Also, if you’ve done any testing with your personal device or have some numbers from a real-world deployment you’d like to share, please let me know in the comments section below. I hope this info helps.
Nick Rintalan, Lead Architect, Americas Consulting, Citrix Consulting