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

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
Introducing kepler.gl, Uber’s Open Source Geospatial Toolbox

Introducing kepler.gl, Uber’s Open Source Geospatial Toolbox

Created by Uber’s Visualization team, kepler.gl is an open source data agnostic, high-performance web-based application for large-scale geospatial visualizations. At Uber, we leverage data visualization to better understand how our cities move. Our solutions enable us to embed maps with rich location data, render millions of GPS points in the blink of an eye, and, most importantly, derive insights from them.

Read More
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