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

Proxygen, Facebook's C++ HTTP Framework

code.facebook.com

Post reply on HN
Print view View original

51–60 of 98 posts

Re: Proxygen, Facebook's C++ HTTP Framework

#51

Post by amelius »

dcsommer wrote: post #42
amelius wrote: post #39

Skimming through the article, it seems to me that this server spawns a thread per connection, is that correct?

We use a very different model actually. Since spawning OS threads is expensive, we opted for the popular nonblocking-IO approach. Each worker thread (usually 1 per core on the CPU) is given connections in a round robin fashion from the listening socket. The worker thread runs an event loop processing events on the accepted socket.

What kind of programming technique did you use to implement the handling of the protocols? Did you implement them as finite-state machines, or did you use coroutines, or some other technique?

Do you think that C++ is a well suited language for this kind of processing? Is it possible to say, now this project is in a mature state, that other languages (e.g. Rust) could have helped make your implementation simpler?

Re: Proxygen, Facebook's C++ HTTP Framework

#52

Post by userbinator »

port8080 wrote: post #12
thomasreggi wrote: post #7

"You will need at least 2 GiB of memory to compile proxygen and its dependencies." What?

fbthrift needs 2GiB of memory to compile ( https://github.com/facebook/fbthrift ) and proxygen has a dependency on fbthrift.

That then begs the question of what in fbthrift needs so much memory... is it mainly due to heavy use of C++ features like template metaprogramming?

Re: Proxygen, Facebook's C++ HTTP Framework

#53

Post by prlin »

egonschiele wrote: post #50
dcsommer wrote: post #44

Earlier quoted context omitted.

I think https://news.ycombinator.com/item?id=8563766 is a good answer to use cases.

Maybe I am being dense, but why is Proxygen a better solution here?

It's a library that you can integrate into your application rather than passing requests via an intermediary (so performance would improve). It's not necessarily a better solution unless you're optimizing for performance. It probably isn't if you're going for ease of development and maintainability.

Re: Proxygen, Facebook's C++ HTTP Framework

#54

Post by johnbellone »

dcsommer wrote: post #23
lost_name wrote: post #20

Earlier quoted context omitted.

This question is a bit naive, but outside of Facebook, can you think of what kind of application this is well suited for?

Well besides the fun of hacking around and building little HTTP servers, I could see this being useful if you want to save money by running fewer instances of your HTTP service. For instance, if you have a widely deployed python webservice that isn't scaling well, you could rewrite it in C++ with very little boilerplate using proxygen's httpserver. It's early stages for the proxygen open source project. Maybe further…

Is that the inception of the project? I am more curious about the lineage. How was the decision made to go this route instead of throwing more instances at it?

Re: Proxygen, Facebook's C++ HTTP Framework

#55

Post by seasonedschemer »

amelius wrote: post #51
dcsommer wrote: post #42

Earlier quoted context omitted.

We use a very different model actually. Since spawning OS threads is expensive, we opted for the popular nonblocking-IO approach. Each worker thread (usually 1 per core on the CPU) is given connections in a round robin fashion from the listening socket. The worker thread runs an event loop processing events on the accepted socket.

What kind of programming technique did you use to implement the handling of the protocols? Did you implement them as finite-state machines, or did you use coroutines, or some other technique? Do you think that C++ is a well suited language for this kind of processing? Is it possible to say, now this project is in a mature state, that other languages (e.g. Rust) could have helped make your implementation simpler?

Hey, I'm a Software Engineer on Proxygen as well. Proxygen heavily relies on folly's buffer management abstractions such as IOBuf (https://github.com/facebook/folly/blob/master/folly/io/IOBuf...) and Cursor (https://github.com/facebook/folly/blob/master/folly/io/Curso...). Protocol parsing implementation uses folly::io::Cursor to safely read byte sequences across non-contiguous buffers. Errors during parsing are wrapped up in Result types (https://github.com/facebook/proxygen/blob/master/proxygen/li...) which take an inspiration from Rust. Such constructs simplify our implementation to a reasonable extent and are still low-level enough to extract performance.

Re: Proxygen, Facebook's C++ HTTP Framework

#56

Post by dcsommer »

johnbellone wrote: post #54
dcsommer wrote: post #23

Earlier quoted context omitted.

Well besides the fun of hacking around and building little HTTP servers, I could see this being useful if you want to save money by running fewer instances of your HTTP service. For instance, if you have a widely deployed python webservice that isn't scaling well, you could rewrite it in C++ with very little boilerplate using proxygen's httpserver. It's early stages for the proxygen open source project. Maybe further…

Is that the inception of the project? I am more curious about the lineage. How was the decision made to go this route instead of throwing more instances at it?

The blog post goes into more detail, but Proxygen started with an effort to write a L7 reverse proxy that could deeply integrate into FB internal services. We pulled out a lot of the non-FB specific stuff into this open source release. Before that, we used hardware load balancers for this role, which was expensive.

Re: Proxygen, Facebook's C++ HTTP Framework

#57

Post by derengel »

bsaul wrote: post #41

Looks to me as facebook's answer to golang ? Building simple, standalone http services with good performances seems to me what those two projects (proxygen and golang) are really about. Now the question is, how much faster using C++ is, and how much safer and faster writing golang is...

I'm guessing that at facebook scale a GC would be expensive.

Re: Proxygen, Facebook's C++ HTTP Framework

#58

Post by nbm »

dcsommer wrote: post #56
johnbellone wrote: post #54

Earlier quoted context omitted.

Is that the inception of the project? I am more curious about the lineage. How was the decision made to go this route instead of throwing more instances at it?

The blog post goes into more detail, but Proxygen started with an effort to write a L7 reverse proxy that could deeply integrate into FB internal services. We pulled out a lot of the non-FB specific stuff into this open source release. Before that, we used hardware load balancers for this role, which was expensive.

By expensive, not just capital costs, but costs around operating them - they weren't as reliably configurable, health-checkable, and instrumentable as we'd want, and Proxygen (and a later L4 load balancer) were.

Also the previous load balancers had constraints we weren't willing to accept - they required special connectivity to our networks, we could not use particular combinations of options, and we had to rely on vendors to solve problems that most of their customers were not encountering and/or able to detect.

Re: Proxygen, Facebook's C++ HTTP Framework

#59

Post by bsaul »

Jare wrote: post #48
bsaul wrote: post #41

Looks to me as facebook's answer to golang ? Building simple, standalone http services with good performances seems to me what those two projects (proxygen and golang) are really about. Now the question is, how much faster using C++ is, and how much safer and faster writing golang is...

I think Facebook is a lot into D, sounds a more appropriate, for lack of a better word, "replacement" for golang.

I thought so as well, but then why release a c++ lib that's supposedly core to your infra ?

Re: Proxygen, Facebook's C++ HTTP Framework

#60

Post by bsaul »

derengel wrote: post #57
bsaul wrote: post #41

Looks to me as facebook's answer to golang ? Building simple, standalone http services with good performances seems to me what those two projects (proxygen and golang) are really about. Now the question is, how much faster using C++ is, and how much safer and faster writing golang is...

I'm guessing that at facebook scale a GC would be expensive.

Compared to google scale which can handle it just fine ? :)))
Post reply on HN