Really curious, are they using async/await?
Pingora, the proxy that connects Cloudflare to the Internet
21–30 of 127 posts
Re: Pingora, the proxy that connects Cloudflare to the Internet
#22Sounds good. I never encountered any performance issues with Cloudflare. If you have the time for enhancement, then: 1. Option to hit the cache before workers. (Why we never use workers). 2. Rules for blocking traffic during nights (time-based rules). 3. Make sure every product is a replacement. If you offer the same thing as a cloud provider. Don’t make us write a lot of custom code.
Could you expand on 3?
Why would you swap Azure blob storage or S3 for anything in Cloudflare if it comes with running custom code in workers?
Re: Pingora, the proxy that connects Cloudflare to the Internet
#23> When crashes do occur an engineer needs to spend time to diagnose how it happened and what caused it. Since Pingora's inception we’ve served a few hundred trillion requests and have yet to crash due to our service code. > In fact, Pingora crashes are so rare we usually find unrelated issues when we do encounter one. Recently we discovered a kernel bug soon after our service started crashing. We've also discovered h…
We had the same experience at work deploying rust services that serve many billions of requests a day as well.
Re: Pingora, the proxy that connects Cloudflare to the Internet
#24Really curious, are they using async/await?
They mentioned they were using tokio, so naturally, yes.
Re: Pingora, the proxy that connects Cloudflare to the Internet
#25Really curious, are they using async/await?
I see quite a bit of
async fn
.await();
Re: Pingora, the proxy that connects Cloudflare to the Internet
#26Sounds good. I never encountered any performance issues with Cloudflare. If you have the time for enhancement, then: 1. Option to hit the cache before workers. (Why we never use workers). 2. Rules for blocking traffic during nights (time-based rules). 3. Make sure every product is a replacement. If you offer the same thing as a cloud provider. Don’t make us write a lot of custom code.
When is night on the internet?
Most—maybe damn near all—sites see significant dips in traffic for at least a few hours a day. Which part of the day, depends on the site. More often than not, it's while the team is asleep and staffing, if any, is at its lowest point, since teams tend to live roughly in the same ~half of the world that their products are most-used in. Plus there's practically no-one in the Pacific until you reach Japan, and not a ton of "Western" sites see much use in Asia, and vice versa, with a few notable exceptions.
It's not unusual for e.g. ecommerce sites to crank up automated fraud prevention "at night" because staffing is so much lower.
TL;DR Most sites' usage patterns exhibit a pronounced day/night cycle that's not too far off from natural day/night cycles where the bulk of the team lives.
Re: Pingora, the proxy that connects Cloudflare to the Internet
#27I wonder how this is deployed to presumably a large number of hosts? Do you build a distribution package out of your Rust build and ship that? If so, what about the Rust standard library? Though I believe some distributions do provide a package for the Rust standard library, but that means one also has to use the packaged rustc/cargo, which tends to lag behind quite a bit.
Rust's standard library is statically linked. Rust binaries typically only require libc (and can be compiled with musl to avoid that dependency too).
Re: Pingora, the proxy that connects Cloudflare to the Internet
#28Does anyone know why nginx used separate processes for workers, instead of threads? This post makes it sound like threads are the way to go, but presumably nginx had a reason for using processes back in the day.
Re: Pingora, the proxy that connects Cloudflare to the Internet
#29Sounds good. I never encountered any performance issues with Cloudflare. If you have the time for enhancement, then: 1. Option to hit the cache before workers. (Why we never use workers). 2. Rules for blocking traffic during nights (time-based rules). 3. Make sure every product is a replacement. If you offer the same thing as a cloud provider. Don’t make us write a lot of custom code.
I agree with #1... Workers before the cache is crazy powerful for the original purpose of Workers (modifying incoming requests). But now that people are starting to use Workers as their original (for remix, etc) it would be nice to be able to have the cache before Workers. As it is right now, having the CDN do full content caching of rendered Remix pages is difficult.
Re: Pingora, the proxy that connects Cloudflare to the Internet
#30Does anyone know why nginx used separate processes for workers, instead of threads? This post makes it sound like threads are the way to go, but presumably nginx had a reason for using processes back in the day.
[deleted]