Latency test between Azure and On-Premises – Part Six

In this test, we’ll be using Function Apps and Logic Apps. Function Apps are a serverless concept of running custom code in Azure. Serverless is capable of scaling when needed. We deployed this C# function that represents the Client Application (but without GUI).


This function calls our  REST Web Service (On-Premises) via Point-to-Site VPN connection to Azure. This can be called on-demand via URL, via Run button on the image, or via Logic Apps.

Important note:
In this scenario, the client makes one single HTTP request, instead of 10 requests as previous scenarios.


This is a Logic App (Designer View). We start by a Recurrence Action, which is a timer set to run each 30 second. When recurrence action is fired, this logic app starts by calling “HttpTriggerCSharp1”, which is the function app showed previously. When this function app is finished, the logic app sends an e-mail to my Create account reporting total execution time.

Finally, this is the e-mail that is sent by our logic app. We can see that total execution time reported by the function app is 63ms. Read on for full results!

Test #6 10kb message

Called by a Logic App trigger, the client makes a HTTP request to our On-Prem Service, receiving a 10kb message, the same as before.


We can see that total execution time was 59ms. This is measured by calling the function app via Run button. We’ll be doing this due to being easier to obtain results. This same result is reported by mail if the function is called by Logic Apps. Execution time oscillated between 47ms and 70ms, being the median value ~59ms. Not bad, and slightly faster than TeamViewer VPN, but slower than direct HTTP request without VPN.

Regarding this same result and comparing it to Site-to-Site VPN, we can see that this method took more ~15ms to execute. This can have a very important influence if you are choosing between PTS and Site-to-Site for your business. Also, Site-to-Site has a more constant flow, while this test was more irregular (had more peaks).

Rest assured that this method works, if you can trade a slight latency increase over cost.

Test #6 100kb message

Now for 100kb message, we’ll repeat the same steps to obtain the results.


As we can verify, the test took 78ms to execute. It peaked 97ms and drops to 68ms. Overall, it took more ~8ms to execute than Site-to-Site but was ~22ms faster than TeamViewer. Regarding direct HTTP request without any VPN, this was slower ~17ms. That’s quite a punch there. Let’s try 5Mb.

Test#6 5mb message

Now to the ultimate 5MB test. No more words needed here.


We can see that this is a deal breaker here. The latency here is way over any other test we did. 3.8s! This may happen due to several reasons, the main ones being:

  1. Function App performance not meeting our requirements,
  2. The way that Azure connects PTS VPN to Function Apps,
  3. Consuming a large data might be doing some memory swaps server-side.

Overall test discussion

Well, this is very surprising. Function Apps is clearly not the way for a large message. The processing is inefficient, therefore takes way too much time. PTS connection to a VM in Azure was faster by more than one second, and surprisingly cheaper!

This solution may still be in Preview, or may have bugs, or maybe it just wasn’t made for this type of usage. Regarding complexity, is clearly simpler to use than a VM, it’s serverless and scalable. You can get rid of VM and make your functions directly accessible via any web browser on any platform.

For exposing your logic in a cleaner, faster way, this is what you need. For data crunching or analytics, it’s also the cleanest way, but if you’re planning to use it to make HTTP requests to your on-prem services, you should consider other options, unless execution time isn’t on the equation.

Read the next post here about relays and service bus!

Leave a Reply

Your email address will not be published. Required fields are marked *