4 ms·

Or 3) you do like golang and erlang and build really lightweight green threads so you get the programming model of approach 1 and nearly the same speed as numbe

Or 3) you do like golang and erlang and build really lightweight green threads so you get the programming model of approach 1 and nearly the same speed as number 2. This of course requires extra effort to prevent blocking of OS threads and in the case where the OS expects thread locality. But IMHO it's the superior approach. The best solution would be if OSes themselves would provide really lightweight threads. And I suspect that they will, eventually.

nickbauman 9y ago
I haven't done Erlang, but in my experience Golang has much the same problems as 1) so I'm not sure I'd agree. +1 to lightweight threads, tho.
- simplify 9y ago
  Phoenix/Elixir can handle 2 million websocket connections on a single box. I would agree myself :) http://www.phoenixframework.org/blog/the-road-to-2-million-websocket-connections http://www.phoenixframework.org/blog/the-road-to-2-million-w...
  - grogenaut 9y ago
    Wouldn't you need something like 40 NICs to do that?
    - phamilton 9y ago
      I believe you are referring to running out of ports, as 65k available ports * 40 ~= 2M. The limitation is actually on a quad tuple: {src_ip, src_port, dest_ip, dest_port} As such, the actual limit is outrageously high and isn't really a problem. Interestingly enough, the referenced Phoenix benchmark overlooked the dest component and hit a limit as they had only 40 or so machines to use in the test. Had they used multiple ips on the server it would have given them a lot more breathing room. EDIT: Multiple IPs != Multiple NICs. You can assign multiple IPs to a single physical interface. Also, they could have used multiple ports to accomplish the same effect.
      - grogenaut 9y ago
        Good to know. I thought you were always limited by the outgoing port range to 65k - (used ports) good to know. So they were limited by the testing cluster or the tested server?
        phamilton 9y ago
        They were limited by the testing cluster, but it was pointed out to them after the fact that they could have used multiple IPs or multiple ports on the tested server to go even higher.
int_19h 9y ago
The problem with this approach is that as soon as you need to call out to a library written in a different language, it has no understanding of your lightweight green threads - precisely because it is currently a language/VM abstraction, not an OS abstraction, so everyone rolls their own. Furthermore, existing languages (notably, C) produce a legacy burden that'll remain even once OSes do start to add such threads. For what it's worth, Win32 has offered a kind of green thread (fibers) for a very long time. Adoption has been minimal, even for other Microsoft products (e.g. .NET doesn't really support them properly).

nickbauman 9y ago

I haven't done Erlang, but in my experience Golang has much the same problems as 1) so I'm not sure I'd agree. +1 to lightweight threads, tho.

simplify 9y ago
Phoenix/Elixir can handle 2 million websocket connections on a single box. I would agree myself :) http://www.phoenixframework.org/blog/the-road-to-2-million-websocket-connections http://www.phoenixframework.org/blog/the-road-to-2-million-w...
- grogenaut 9y ago
  Wouldn't you need something like 40 NICs to do that?
  - phamilton 9y ago
    I believe you are referring to running out of ports, as 65k available ports * 40 ~= 2M. The limitation is actually on a quad tuple: {src_ip, src_port, dest_ip, dest_port} As such, the actual limit is outrageously high and isn't really a problem. Interestingly enough, the referenced Phoenix benchmark overlooked the dest component and hit a limit as they had only 40 or so machines to use in the test. Had they used multiple ips on the server it would have given them a lot more breathing room. EDIT: Multiple IPs != Multiple NICs. You can assign multiple IPs to a single physical interface. Also, they could have used multiple ports to accomplish the same effect.
    - grogenaut 9y ago
      Good to know. I thought you were always limited by the outgoing port range to 65k - (used ports) good to know. So they were limited by the testing cluster or the tested server?
      - phamilton 9y ago
        They were limited by the testing cluster, but it was pointed out to them after the fact that they could have used multiple IPs or multiple ports on the tested server to go even higher.

int_19h 9y ago

The problem with this approach is that as soon as you need to call out to a library written in a different language, it has no understanding of your lightweight green threads - precisely because it is currently a language/VM abstraction, not an OS abstraction, so everyone rolls their own. Furthermore, existing languages (notably, C) produce a legacy burden that'll remain even once OSes do start to add such threads. For what it's worth, Win32 has offered a kind of green thread (fibers) for a very long time. Adoption has been minimal, even for other Microsoft products (e.g. .NET doesn't really support them properly).