Serverless Performance: Cloudflare Workers, Lambda and Lambda@Edge

Serverless Performance: Cloudflare Workers, Lambda and Lambda@Edge

  • July 3, 2018
Table of Contents

Serverless Performance: Cloudflare Workers, Lambda and Lambda@Edge

A few months ago we released a new way for people to run serverless Javascript called Cloudflare Workers. We believe Workers is the fastest way to execute serverless functions, but lets prove it. At the 95th percentile, Workers is 441% faster than a Lambda function, and 192% faster than Lambda@Edge.

The functions being tested simply return the current time. All three scripts are available on Github. The testing is being done by a service called Catchpoint which has hundreds of testing locations around the world.

To be fair, comparing my Lambda, which only runs in us-east-1 (Northern Virginia, USA), to a global service like Workers is a a little unfair. This effect becomes even more clear if I only show tests ran in Australia. Sydney is 9,735 miles (53 light-ms) from our instance in us-east-1.

It becomes pretty clear how miserable the experience would be for visitors down south: As we only run one instance of each test from Australia every five minutes that’s not a conclusive amount of data though, so let’s look at the percentile distribution for the past 24 hours: The 50th percentile speed for Workers is 13ms, well faster than a packet could even get half way to Virginia. At the 95th percentile you’re looking at 882ms for Lambda, 216ms for Lambda@Edge, and 40ms for Workers.

A full 5% of your users will be waiting almost a second for the simplest possible Lambda response, making it impossible to build a responsive application. As we said, Workers has quite the advantage being deployed everywhere, as compared to Lambda which lives in a single region. (Lambda@Edge has less of an excuse).

We believe Worker performance should be great everywhere though, so lets look a little closer to our Lambda instance. First all the tests in North America:

Source: cloudflare.com

Share :
comments powered by Disqus

Related Posts

Growing the Data Visualization Community with deck.gl v5

Growing the Data Visualization Community with deck.gl v5

Today, the Uber Visualization team open sourced deck.gl 5.3, the final deck.gl v5 release of our data visualization software. The v5 releases represent a major effort devoted to making deck.gl easier to use than ever before, and we hope that by sharing the story behind these improvements, we can get users excited to try out deck.gl v5’s new simplified APIs and features. While a lot of code required modification, the most important part of making deck.gl independent from React was deciding how the new non-React-based API should look.

Read More
Things I’ve learned using serverless

Things I’ve learned using serverless

After the tour-de-force of Serverlessconf in October, I decided my entire company would be going serverless. I spent the first couple of months beating my head against the wall trying to migrate a Python Flask app to Lambda—these efforts helped me find a better way.

Read More
Reconciling GraphQL and Thrift at Airbnb

Reconciling GraphQL and Thrift at Airbnb

For several years, we had a few eager advocates for GraphQL at Airbnb, but the project never quite made it through the gates largely due to the perception that “GraphQL the Religion”—a worldview where all data is a graph all the way down—would be incompatible with our particular services-oriented architecture (SOA) strategy, which defines service-to-service communication using Thrift Interface Definition Language (IDL) and delivers data to clients via dedicated Presentation Services. We recently reframed a case for “GraphQL the API Layer.” Embracing how GraphQL could complement rather than compete with our Presentation Services, it found much more traction.

Read More