7 ms·

Interesting to see that they use Erlang. http://www.erlang-factory.com/conference/SFBay2012/speakers/RickReed http://www.erlang-factory.com/conference/SFBay2012

Interesting to see that they use Erlang. http://www.erlang-factory.com/conference/SFBay2012/speakers/RickReed http://www.erlang-factory.com/conference/SFBay2012/speakers/... I wonder if this is still valid?

emaste 13y ago
Yes, here's a quote from the FreeBSD Foundation's July 2013 newsletter: At WhatsApp we leverage FreeBSD and Erlang to provide industry record uptime. The ability to scale linearly on commodity hardware has allowed WhatsApp to keep our serving costs low. These days we run anywhere between 2 million and 3 million concurrent TCP connections on a single FreeBSD server... https://www.freebsdfoundation.org/press/2013Jul-newsletter#whatsapp https://www.freebsdfoundation.org/press/2013Jul-newsletter#w...
- tostitos1979 13y ago
  Wow! 2-3 million concurrent TCP connections? I just discovered C10K last year :( Is this a fundamental difference between thread based networking and evented network IO? What am I missing?
  - strmpnk 13y ago
    Not exactly. While there are ways to conflate a connection with a thread, these are not always fixed pairs. Generally, it depends on the kind of connection activity and a bit on which operating system. Event based IO is simply pushing information that kernel schedulers already use into user space. The trade-offs really depend on where you need control the most. Many kernels can do a pretty good job at general purpose networking but at this scale you tend to care about the details and so more of these systems tend to push the decision making to the program using APIs like epoll & kqueue (Linux and *BSD respectively). Keeping this information transfer cheap for millions of sockets is not as trivial as just using the API but it's a necessary step to control overhead. Whether your user space code uses threads in places to get work done is often misunderstood as well since thread doesn't always mean a single logical thread in a program. Erlang, in SMP mode, uses threads to run it's own process schedulers (much like an operating system). The operation of these schedulers is handled in such a way that IO can efficiently block a process and the scheduler can move onto other things in queue. So, in many ways, it's the same ideas we had on the bare OS but with more specific implementation governed by Erlang's philosophy.

emaste 13y ago

Yes, here's a quote from the FreeBSD Foundation's July 2013 newsletter: At WhatsApp we leverage FreeBSD and Erlang to provide industry record uptime. The ability to scale linearly on commodity hardware has allowed WhatsApp to keep our serving costs low. These days we run anywhere between 2 million and 3 million concurrent TCP connections on a single FreeBSD server... https://www.freebsdfoundation.org/press/2013Jul-newsletter#whatsapp https://www.freebsdfoundation.org/press/2013Jul-newsletter#w...

tostitos1979 13y ago
Wow! 2-3 million concurrent TCP connections? I just discovered C10K last year :( Is this a fundamental difference between thread based networking and evented network IO? What am I missing?
- strmpnk 13y ago
  Not exactly. While there are ways to conflate a connection with a thread, these are not always fixed pairs. Generally, it depends on the kind of connection activity and a bit on which operating system. Event based IO is simply pushing information that kernel schedulers already use into user space. The trade-offs really depend on where you need control the most. Many kernels can do a pretty good job at general purpose networking but at this scale you tend to care about the details and so more of these systems tend to push the decision making to the program using APIs like epoll & kqueue (Linux and *BSD respectively). Keeping this information transfer cheap for millions of sockets is not as trivial as just using the API but it's a necessary step to control overhead. Whether your user space code uses threads in places to get work done is often misunderstood as well since thread doesn't always mean a single logical thread in a program. Erlang, in SMP mode, uses threads to run it's own process schedulers (much like an operating system). The operation of these schedulers is handled in such a way that IO can efficiently block a process and the scheduler can move onto other things in queue. So, in many ways, it's the same ideas we had on the bare OS but with more specific implementation governed by Erlang's philosophy.