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

Pingora, the proxy that connects Cloudflare to the Internet

blog.cloudflare.com

Post reply on HN
Print view View original

91–100 of 127 posts

Re: Pingora, the proxy that connects Cloudflare to the Internet

#91

Post by ddorian43 »

totallyunknown wrote: post #89
BonoboIO wrote: post #71

Earlier quoted context omitted.

Es liegt mir auf der Zunge welche Firma das ist. I think it starts with a Wa ... you don’t have to say. I kind of remember to have been stumbled on a Twitter engineering ipv6 tweet. Maybe I m wrong. For me it’s impressive to get so much data through a computer. But I have one question, what does count as a node, is a node like 1 machine with dual sockets, a lot of ram and a lot of nics or is it like multiple machines…

A single node is single socket AMD EPCY node with 32 cores, 64 or 128GB RAM, 1x NIC with 2x100 GB/s. Ja, es ist waipu.tv.

What about the disks?

Edit: or linear TV means the recent stream can be all in ram?

Re: Pingora, the proxy that connects Cloudflare to the Internet

#92

Post by costela »

lossolo wrote: post #74
totallyunknown wrote: post #64

Earlier quoted context omitted.

A german company building an app for watching linear TV. Netflix is actually serving 400Gbit/s per node and already have 800Gbit/s ready. I think we can scale our setup up to 200 Gbit/s but we are too small. Total traffic is ~2 Tbit/s. Most challenging is the missing support of QUIC/http3 and KTLS in Golang. Also 100G NIC supply chain is difficult. We use NVIDIA Connect-X 6, but it's impossible to get a version with…

Interesting, do you do a lot of processing in Golang or basically you just use it as a wrapper around sendfile[1] ? 1. https://man7.org/linux/man-pages/man2/sendfile.2.html

and yes: the proxy does have some intelligence around "just" forwarding requests. Mostly caching related, but also some upstream routing decisions and a ton of observability.

Re: Pingora, the proxy that connects Cloudflare to the Internet

#93

Post by totallyunknown »

ddorian43 wrote: post #91
totallyunknown wrote: post #89

Earlier quoted context omitted.

A single node is single socket AMD EPCY node with 32 cores, 64 or 128GB RAM, 1x NIC with 2x100 GB/s. Ja, es ist waipu.tv.

What about the disks? Edit: or linear TV means the recent stream can be all in ram?

All in memory.

Re: Pingora, the proxy that connects Cloudflare to the Internet

#95

Post by otikik »

rkagerer wrote: post #42
nicoburns wrote: post #6

> 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…

Which aspect(s) of Rust do you think are most responsible for this? (e.g. borrow checker, memory safety, culture that attracts devs who care about reliability, etc)

I think ultimately the big thing Rust brings to the table is that a lot of Rust's features is geared towards detecting problems as early as possible.

This means you get complexity, especially on the "initial phases".

* The initial learning curve is steeper than usual . You have x types of string instead of one or two, you have lifetimes, etc, etc. Fortunately you pay it once and then can use it many times (maybe with some revisits to the docs :P)

* The initial building of a feature might take a bit longer than in other less complex languages (the borrow checker gives you a particularly tricky error, etc). But what is happening here is that the language is picking up problems that other languages ... don't. They "defer to production".

Others are mentioning that cargo is another feature that helps. I think it does, but indirectly. What cargo does is improving the developer experience. Having all the packages at the tip of your fingers, without needing to jump over hoops like in other languages is just ... nice. Given the initial ramp up in complexity, and the initial harder-than-usual first write, anything that improves the UX goes towards alleviating that. I personally would put cargo on the same bucket as "helpful compiler messages" and "good docs".

Re: Pingora, the proxy that connects Cloudflare to the Internet

#96

Post by qwertox »

nextaccountic wrote: post #68
qwertox wrote: post #63

Earlier quoted context omitted.

In some cases it can be enough to know that it could be worth waiting for the release instead of putting more resources into a stack you're currently using. You might replace it entirely in a few months if the release turns out to be a product which you can and want to switch to, so it's ok to get a heads-up.

Unfortunately, without being able to run the code yourself or at least seeing a benchmark, it's hard to commit to unreleased code like this

True. But you're not committing to it, you're just waiting for the evaluation instead directing resources into a change which might become obsolete soon, should the new option be a viable one.

In this case, where the code is coming from Cloudflare, you can be sure that they know what they're doing, that there is a high chance that it will be very high quality code.

Apart from this, it's an interesting article from a technical perspective due to the various topics it touches.

Also, in my case, where I'm looking for an new language to program in, where Rust and Go are the my main options, articles like these help me with the decision process on which one to choose.

There's much more value to this article than it just being an announcement that sometime in the near future they will be releasing an open source project.

It almost sounded like a "give me the code or shut up"-message.

Re: Pingora, the proxy that connects Cloudflare to the Internet

#97

Post by botanicalfriend »

latchkey wrote: post #66
eastdakota wrote: post #3

Earlier quoted context omitted.

We are planning on open sourcing it. That's mentioned in the post near the end.

It is kind of weird to point out nginx doing closed door development as a negative, and then do exactly the same thing yourself.

The “closed door development” is a problem for their business. They don’t have that problem when they maintain it, free software aside.

Re: Pingora, the proxy that connects Cloudflare to the Internet

#98

Post by 1vuio0pswjnm7 »

thayne wrote: post #80
1vuio0pswjnm7 wrote: post #78

Besides comparing this to Nginx plus Lua (OpenResty), has Cloudflare compared it to Haproxy plus Lua or any other similar proxies. The main issue for me with Rust is that it takes significantly more resources (time, space, memory, CPU) to build projects from source. Building Haproxy is comparatively quick and easy. The haproxy plus lua static binary (musl, no pcre) I use is already growing rather large. I will bet th…

I really love haproxy, but I have seen segfaults and other memory errors thay wouldn't have happened if it had been written in rust (not that that was an option when haproxy was originally written). If you are going to write a new http software from scratch, I definitely think rust is a good language to use. I would have liked to have seen more explanation of why they decided to build their own rather than use haprox…

I have never experienced a segfault or other memory errors with haproxy. How can I reproduce the errors you describe.

Re: Pingora, the proxy that connects Cloudflare to the Internet

#99

Post by thayne »

1vuio0pswjnm7 wrote: post #98
thayne wrote: post #80

Earlier quoted context omitted.

I really love haproxy, but I have seen segfaults and other memory errors thay wouldn't have happened if it had been written in rust (not that that was an option when haproxy was originally written). If you are going to write a new http software from scratch, I definitely think rust is a good language to use. I would have liked to have seen more explanation of why they decided to build their own rather than use haprox…

I have never experienced a segfault or other memory errors with haproxy. How can I reproduce the errors you describe.

I don't know of any current ones. Because when I have encountered them, I've reported them and the haproxy maintainers fixed them quickly, and backported the fixes to still maintained older versions.

I don't remember the exact specifics off the top of my head, but in one case a certain kind of invalid config resulted in a crash rather than a normal error message. In another, there was an error in a bounds check, where if you chained multiple converters in the right way, you could end up capturing some additional data from other http headers.

Post reply on HN