A quick answer would be, ‘Yes, Replify can accelerate the internet and bring benefits when accelerating general internet traffic.’ But to get the best out of the WAN caching and acceleration, we wanted to dig a bit deeper into the finer details of the optimization.
We’ve previously written about how Replify WAN Accelerator can help improve the performance for cloud services and indeed for general internet traffic. In these articles we mentioned that configuring this requires some understanding about the nature of the traffic. What type of data is it? Where are the servers located? What protocols are being used?
In practice, many organizations lack a clear idea of how their internet connection is being used. To get a clearer view of this, some organisations will implement some form of visibility or traffic monitoring solution.
Using WAN Optimization to Accelerate the Internet
As part of our ongoing testing at Replify, everyone can accelerate the internet traffic on their connection using the latest development version of the Replify WAN Accelerator. When working from home, they run the Replify Accelerator Client on their device. This is connected to a Replify Virtual Appliance hosted in Microsoft Azure. One great benefit of this, is that it gives us an another source of feedback, in addition to our unit and system testing. We’ll all know very quickly if someone has committed code that has broken something fundamental!
This all puts us in a special position where we have continuous access to optimisation metrics about general internet traffic. We can then examine these to better understand how well the acceleration is working and what type of optimisation suit that web traffic. Ultimately it means Replify can accelerate the Internet from almost any type of connection.
What We Learned
Percentage Offload is Only Part of the Story
We noticed that the traffic with the highest offload isn’t the traffic that we provide the greatest percentage offload for.
For example we noticed that one employee had put over 3GB of video traffic through the VA in a day. While many listen to music and podcasts, having a long running Twitch stream also isn’t uncommon. We typically wouldn’t expect much here as video traffic is already well optimized. However for Twitch the offload was around 20%. Even though this is a low offload figure, it was the application which resulted in the highest data saving for that day. That’s because 20% of 3GB is much better than 90% of all the traffic to News websites for example.
CDNs and WAN Optimization Work Well Together
Most of our highest offload was for traffic from CDN services. For example Akamai, Fastly etc. This shows that while CDN does a great job of mitigating against the effects of latency, using WAN caching and optimization still brings huge benefits.
For example, https://www.replify.com is hosted in the UK and uses Cloudflare for CDN. This means that if a user in Australia tries to access our website, they are directed to a Cloudflare server in Australia and they see the website having 30ms latency instead of 300ms latency. If a user has a good quality internet connection, that will really improve their user experience. However if that user is on a 3G/4G connection and wants to download a large file from our site, this may still be slow. Replify Accelerator can be used with that 3G/4G connection adding an extra performance boost onto that which Cloudflare already provides.
Our Services were Configured in the Correct Region
Using ntopng, we were able to determine where in the world our traffic was destined for. The majority of it was to the UK and Ireland. This revealed to us that our UK based appliance was in a good location. That is, it is hosted close to the services that need optimized.
However we did see a few hundred MB going to servers in Canada. In our case, we could see that the traffic wasn’t business critical. However if it was, it would have indicated that adding a second appliance to deal with this traffic may have been worthwhile.
Some Services don’t Optimize Well
There were several services where Replify Accelerator was providing worthwhile optimization benefit. One of these was for an ad-tracking service. We didn’t delve into the details of this but it was likely to include compressed traffic. Trying to compress/cache such traffic is a waste of effort. Turning off compression and caching would free up resources for more worthwhile traffic.
Alternatively blocking this traffic with a firewall rule could do wonders as well.
We obtained many of the insights above simply from looking at the destination IP address and the offload statistics.
Due to the nature of what Replify Accelerator does, it has access to decrypted HTTPS traffic payload. This means that if we wanted to, we could inspect the traffic further and collate more detailed statistics at a more granular level. For example, request headers, object types, and URLs web traffic.