3 ms·

I'm curious, does anyone know if this has been implemented somewhere and has actually been profiled? Just because something can open a million connections does

by icey 18y ago

I'm curious, does anyone know if this has been implemented somewhere and has actually been profiled? Just because something can open a million connections doesn't mean it's stable enough to be a million-user application.

alecco 18y ago
A stress test for several days and fully networked stacks can give you an idea. And in my experience C/libevent would be hard to beat there by anything as there are less things that can block service. A classic is seeing the garbage collector going bananas for a few seconds in object-oriented languages.
axod 18y ago
You would need a lot of ram to service a million users on a single server and actually do something useful with them. Input/output buffers alone would amount to a lot (Several gigs most likely) I've run things up to around 50k in practice (Not erlang, java). Stability isn't an issue really, mainly ram.
- alecco 18y ago
  The memory issue is Java. Not for event-based C. (Don't believe me, go to the language shootout and see Java vs. whatever and look at the memory use.) Also what does "a million users" mean? A million open connections? How many requests active simultaneously? One million simultaneous HTTP requests would sure eat a lot of memory, but who does it that way? It's stupid. The kernel handles socket buffers for you. Each processor core can only read one socket at a time. So as long as you don't take too much longer to respond requests you should be fine. Plus with things like event based libraries you can just place a read on the socket for at least X size to "wait" till the basic of the request is fulfilled. I don't know what they are trying to do, it all depends on what the server does. For pure messaging across connections it should be an order of magnitude better in C/libevent. But as I say, I need more info.
  - axod 18y ago
    Yes java adds some overhead, but you still have the low level buffers. A million open connections we're talking about. All active, connected. Agreed, c/assembly would obviously reduce the memory footprint. But is the extra work worth it? I'd say not for most apps.
  - alecco 18y ago
    D'oh, from TFP: This code (mochiconntest_web.erl) just accepts connections and uses chunked transfer to send an initial welcome message, and one message every 10 seconds to every client. 1000000 / 10 = 100000 writes per second to a client on a connected socket. My guesstimate is it's not that much :) Based on this graph: http://monkey.org/~provos/libevent/libevent-benchmark2.jpg http://monkey.org/~provos/libevent/libevent-benchmark2.jpg [BTW sorry for replying to my own comment, and sorry I didn't read TFA.]

by icey 18y ago

alecco 18y ago

A stress test for several days and fully networked stacks can give you an idea. And in my experience C/libevent would be hard to beat there by anything as there are less things that can block service. A classic is seeing the garbage collector going bananas for a few seconds in object-oriented languages.

axod 18y ago

You would need a lot of ram to service a million users on a single server and actually do something useful with them. Input/output buffers alone would amount to a lot (Several gigs most likely) I've run things up to around 50k in practice (Not erlang, java). Stability isn't an issue really, mainly ram.

alecco 18y ago
The memory issue is Java. Not for event-based C. (Don't believe me, go to the language shootout and see Java vs. whatever and look at the memory use.) Also what does "a million users" mean? A million open connections? How many requests active simultaneously? One million simultaneous HTTP requests would sure eat a lot of memory, but who does it that way? It's stupid. The kernel handles socket buffers for you. Each processor core can only read one socket at a time. So as long as you don't take too much longer to respond requests you should be fine. Plus with things like event based libraries you can just place a read on the socket for at least X size to "wait" till the basic of the request is fulfilled. I don't know what they are trying to do, it all depends on what the server does. For pure messaging across connections it should be an order of magnitude better in C/libevent. But as I say, I need more info.
- axod 18y ago
  Yes java adds some overhead, but you still have the low level buffers. A million open connections we're talking about. All active, connected. Agreed, c/assembly would obviously reduce the memory footprint. But is the extra work worth it? I'd say not for most apps.
- alecco 18y ago
  D'oh, from TFP: This code (mochiconntest_web.erl) just accepts connections and uses chunked transfer to send an initial welcome message, and one message every 10 seconds to every client. 1000000 / 10 = 100000 writes per second to a client on a connected socket. My guesstimate is it's not that much :) Based on this graph: http://monkey.org/~provos/libevent/libevent-benchmark2.jpg http://monkey.org/~provos/libevent/libevent-benchmark2.jpg [BTW sorry for replying to my own comment, and sorry I didn't read TFA.]