Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Serverless Performance: Cloudflare Workers, Lambda and LambdaEdge

blog.cloudflare.com

Post reply on HN
Print view View original

31–40 of 65 posts

Re: Serverless Performance: Cloudflare Workers, Lambda and LambdaEdge

#31

Post by ranman »

kentonv wrote: post #20
bufferoverflow wrote: post #15

Does Cloudflare have a free DB of sorts, like Amazon's DynamoDB? Or can I query Amazon's DynamoDB from the worker?

Building out storage is my current focus. The challenge is that we want to build something that actually utilizes out network of 151 locations today, 1000's of locations in the future. If your application has users on Mars (or, New Zealand), you should be able to store their data at the Cloudflare location on Mars (or, New Zealand) so that they can get to it with minimal latency. PS. If you're a storage expert and bu…

Let me know if you need help with the Mars location in the future. I can't wait for AWS to open their utopia-planitia-1 region with SpaceX or BlueOrigin.

Re: Serverless Performance: Cloudflare Workers, Lambda and LambdaEdge

#32

Post by greenail »

zackbloom wrote: post #10
jedberg wrote: post #5

The value of any function-as-a-service is the ecosystem within which it sits. Pretty much all of them are the same: upload your code, we will run it. The value comes from 1) What can trigger that code to run and 2) What services that code can interact with. And on those two points, AWS still wins hands down. They have by far the most possible triggers for Lambda, and they have by far the most services that Lambda can…

Yes, that's how Amazon creates lock-in. But it depends what you're doing with it right? If you are looking to run code based on a SQS event, yes you have to use a Lambda. If you are looking to execute code when something visits a URL you have more options.

The lockin argument alone is a red herring. Every technology implementation creates lockin. The valid question is how hard is something to change. A good architecture balances how easy it is to change something with how optimized it is, also balancing how much it costs to build and maintain.

Realistically you can get as locked into Amazon as you want, lambda alone does not create inescapable lockin by any measure so I would argue Jeremy still has a point in the fact that tools become more useful when you can use them to do more work (ecosystem)...

Re: Serverless Performance: Cloudflare Workers, Lambda and LambdaEdge

#33

Post by mrkurt »

BillinghamJ wrote: post #21
mrkurt wrote: post #6

Comparing Workers to Lambda proper seems silly. Lambda lets you connect to DBs, use a lot more than 128MB of memory, etc, etc, etc. Comparing them to Lambda@Edge makes sense, but Lambda@Edge is not a very good product. (Full disclosure: my company competes with Cloud Flare Workers).

Could you expand on your opinion of Lambda@Edge? For my company's needs, it has worked superbly.

Sure! I think it's fine infrastructure-wise, but the dev experience is awful. I like tools you can build, test and run locally, for example.

The fundamental problem I run into with Lambda@Edge is just that their request stages aren't a great abstraction (OpenResty/nginx has a similar problem). It really limits what kinds of problems you can solve.

Re: Serverless Performance: Cloudflare Workers, Lambda and LambdaEdge

#34

Post by prdonahue »

smoll wrote: post #23

What Infrastructure as Code (IaC) options exist for Cloudflare Workers? AFAICT neither Serverless nor Terraform support it. IaC is table stakes for any new part of my tech stack, and I would prefer not to code it from scratch - unless deployment/configuration is extremely easy to automate via CLI or something...

To expand on what Zack said, we're just about ready to merge in Cloudflare Workers support to our golang SDK (see https://github.com/cloudflare/cloudflare-go/pull/188).

Once this is merged, it clears the way for us adding Terraform support (as terraform-provider-cloudflare wraps cloudflare-go).

There's been lots of interest from our customers in being able to manage Workers using Terraform, so it's high on the list.

Re: Serverless Performance: Cloudflare Workers, Lambda and LambdaEdge

#35

Post by kentonv »

mrkurt wrote: post #33
BillinghamJ wrote: post #21

Earlier quoted context omitted.

Could you expand on your opinion of Lambda@Edge? For my company's needs, it has worked superbly.

Sure! I think it's fine infrastructure-wise, but the dev experience is awful. I like tools you can build, test and run locally, for example. The fundamental problem I run into with Lambda@Edge is just that their request stages aren't a great abstraction (OpenResty/nginx has a similar problem). It really limits what kinds of problems you can solve.

> The fundamental problem I run into with Lambda@Edge is just that their request stages aren't a great abstraction (OpenResty/nginx has a similar problem). It really limits what kinds of problems you can solve.

Yes! I completely agree. Interesting that we both ended up with the Service Workers API instead. I'm really hoping that Service Workers becomes the standard for JavaScript HTTP handling in the future.

Re: Serverless Performance: Cloudflare Workers, Lambda and LambdaEdge

#36

Post by 1996 »

greenail wrote: post #32
zackbloom wrote: post #10

Earlier quoted context omitted.

Yes, that's how Amazon creates lock-in. But it depends what you're doing with it right? If you are looking to run code based on a SQS event, yes you have to use a Lambda. If you are looking to execute code when something visits a URL you have more options.

The lockin argument alone is a red herring. Every technology implementation creates lockin. The valid question is how hard is something to change. A good architecture balances how easy it is to change something with how optimized it is, also balancing how much it costs to build and maintain. Realistically you can get as locked into Amazon as you want, lambda alone does not create inescapable lockin by any measure so…

Amazon performance is generally bad when using other services.

We are rolling out a CDN, with a goal of 20 ms latency in most countries. We want more granularity that AWS - and some zones are just not well served (No AWS in Africa, incomplete offer in Brasil, etc)

Still, we figured we would use Route 53 as you can do Latency Based Routing even with non-AWS servers. Computing latency or using EDNS0 as a proxy is not rocket science, so we thought the DNS would not be a limiting point.

Oh boy, how wrong we were! After wrongly blaming the bad performance on Cloudflare caching, further tests revealed Route 53 takes as much as 0.7s to reply to some DNS queries - and even worse when fronted by Cloudflare, as for some reason the DNS TTL seems to be ignored by Cloudflare. The latency only drops down after about 4 queries, which makes me thing they have some kind of Round-Robin that does not share the DNS queries (I could be wrong)

In the article, the author says: "Most of that delay is DNS however (Route53?). Just showing the time spent waiting for a response (ignoring DNS and connection time)". No you should not ignore the DNS delays! Route53 performance is very bad - 2 full seconds for you!!

We are fortunate it did not take 2s for us. Still, having servers all over the world that reply in 20 ms is useless when the first DNS query takes 700ms.

We ended up leaving for Azure: Traffic Manager outperforms Route 53 by a factor of 2.

Eventually, we will roll our own GeoIP with DNS resolvers on a anycast subnet.

I do not understand how this level of "performance" can be tolerated. At 2 seconds for a DNS query, you are better off using the registrar free DNS service!!

Re: Serverless Performance: Cloudflare Workers, Lambda and LambdaEdge

#37

Post by 1996 »

kentonv wrote: post #17

As the architect of Workers I was obviously pretty happy with Zack's results in general. But, I'm not happy with the tail latency (99th percentile), even if it beats the competition. I suspect this has to do with GC pauses. The solution may be to proactively run GC in a background thread between requests. For high-traffic workers that are always processing requests, we could load multiple instances of the worker and…

You are from Cloudflare? Could you tell me why the replies to geoip/latency based routing CNAMEs do not seem to be cached by Cloudflare?

The setup is: domain.com -> geoiplbr.domain.com with cloudflare caching enabled. Nothing else that is fancy and could cause delays.

If I measure the TTFB for domain.com, I see a large DNS delay until about the 4th consecutive query - and then the DNS is no longer the limiting factor.

The same measures on geoiplbr.domain.com normalize after the 2nd query.

It seems to me you have some kind of Roud Robin going on that does not share the DNS results.

Or maybe the caching is not done at the POP level?

Re: Serverless Performance: Cloudflare Workers, Lambda and LambdaEdge

#38

Post by zackbloom »

BillinghamJ wrote: post #21
mrkurt wrote: post #6

Comparing Workers to Lambda proper seems silly. Lambda lets you connect to DBs, use a lot more than 128MB of memory, etc, etc, etc. Comparing them to Lambda@Edge makes sense, but Lambda@Edge is not a very good product. (Full disclosure: my company competes with Cloud Flare Workers).

Could you expand on your opinion of Lambda@Edge? For my company's needs, it has worked superbly.

If you happen to give Workers a try we would love to hear what you think -> zack [at] cloudflare.com

Re: Serverless Performance: Cloudflare Workers, Lambda and LambdaEdge

#40

Post by iamleppert »

This really isn't a very good benchmark. It's basically only validating the Cloudflare edge network, but the test itself is far from real-world. A service that returns the current time is not doing anything practical and borders on meaningless.
Post reply on HN