3 ms·

1) Notice that in his tests 97% of these connections don't do anything, just idle. He maxes out at 18764 req/sec. If you google around, Apache and Nginx can do

by rorrr 14y ago

1) Notice that in his tests 97% of these connections don't do anything, just idle. He maxes out at 18764 req/sec. If you google around, Apache and Nginx can do more than that on a beefy server. 2) Notice that they are "keep-alived", coming from the same IP, so not truly separate connections. 3) Keep in mind that 600K concurrent connections cannot possibly do anything useful at the same time for many reasons (CPU, bandwidth, server I/O), so they are not truly concurrent. 4) Max concurrent connections are also limited by the OS, and that limit is much much lower than 600K by default: http://serverfault.com/questions/10852/what-limits-the-maximum-number-of-connections-on-a-linux-server http://serverfault.com/questions/10852/what-limits-the-maxim...

programnature 14y ago
but is this an apple-to-apple comparison to the node.js results referenced in the post?
- codeka 14y ago
  It seems to me it's not because the Node.js test used a remote machine to drive the connections whereas this one is driving the connections from the same machine. Running the server and test harness on the same machine bypasses a whole lot of networking stack. Also, it seems the limitation in Node.js is the maximum heap size of around 1.4GB [1]. This test used a heap size of 3GB which is just not possible in Node (until the limitation is removed, anyway). [1]: http://blog.caustik.com/2012/04/10/node-js-w250k-concurrent-connections/ http://blog.caustik.com/2012/04/10/node-js-w250k-concurrent-...
  - shenedu 14y ago
    author here. Yes, Clojure can use more than 1.4G of heap, and can use threads. http-kit is multithreaded (one just for IO, others for computing response). A strength of Clojure?
    - notimetorelax 14y ago
      Frankly as somebody pointed out http-kit is written mostly in Java, so I would say that you're showing strength of JVM.
      - shenedu 14y ago
        Yes, JVM is strong. Clojure inherit it.
shenedu 14y ago
author here. > Notice that in his tests 97% of these connections don't do anything, just idle. He maxes out at 18764 req/sec. Yes, just testing how many concurrent connection can be held. When the 600k are held, ab confirms that it can do about 31405.53 per seconds, the http body is 1024bytes. > Notice that they are "keep-alived", coming from the same IP, so not truly separate connections Not from the same ip, from many ips: 192.168.1.200~230 > Keep in mind that 600K concurrent connections cannot possibly do anything useful at the same time for many reasons (CPU, bandwidth, server I/O), so they are not truly concurren They send a request every 5s~30s to server, and wait for response
- rorrr 14y ago
  > Not from the same ip, from many ips: 192.168.1.200~230 So from 31 IPs, which can be done with 31 keepalive connections. Try hitting your server with even 50K real connections and see how long it lasts (if it lasts at all). > They send a request every 5s~30s to server, and wait for response Exactly. ALL of them don't do anything concurrently, they just sit idly.
  - alexkus 14y ago
    You seem to be missing the point of the scenario they're testing. Lots of idle connections (doing overlapping long polling) is exactly how many COMET servers work. We send ~60 "events" via our COMET server (APE from www.ape-project.org) in a typical 2 hour period. The server side work to decide when/what to send the clients is easy because it's the same information that gets sent whether there is 1 connection or 1,000,000. The fact they're from just 31 different IP addresses isn't relevant. They're still individual connections from clients to the end server.
    - rorrr 14y ago
      > The fact they're from just 31 different IP addresses isn't relevant. They're still individual connections from clients to the end server. That's where you are wrong. Not only they are keepalive connections, they are completely local. Do it over an actual network from 50K different IPs and see how that performs.
jlouis 14y ago
I want to make an important point on 3) If you have 600K concurrent connections they are concurrent. You could have them on a single core, limited severely on bandwidth and disk I/O. What you don't have is parallelism, since they are not executing at the same time. I feel that this distinction is important to make. That most of them are waiting on a given event to happen does not make it any less concurrent, but it does limit the amount of parallelism which is possible. On a single core machine, the operating system is concurrently executing processes, perhaps a hundred of those. But only one process can be on the CPU at a time, so the parallelism count is always either 0 or 1.

by rorrr 14y ago

programnature 14y ago

but is this an apple-to-apple comparison to the node.js results referenced in the post?

codeka 14y ago
It seems to me it's not because the Node.js test used a remote machine to drive the connections whereas this one is driving the connections from the same machine. Running the server and test harness on the same machine bypasses a whole lot of networking stack. Also, it seems the limitation in Node.js is the maximum heap size of around 1.4GB [1]. This test used a heap size of 3GB which is just not possible in Node (until the limitation is removed, anyway). [1]: http://blog.caustik.com/2012/04/10/node-js-w250k-concurrent-connections/ http://blog.caustik.com/2012/04/10/node-js-w250k-concurrent-...
- shenedu 14y ago
  author here. Yes, Clojure can use more than 1.4G of heap, and can use threads. http-kit is multithreaded (one just for IO, others for computing response). A strength of Clojure?
  - notimetorelax 14y ago
    Frankly as somebody pointed out http-kit is written mostly in Java, so I would say that you're showing strength of JVM.
    - shenedu 14y ago
      Yes, JVM is strong. Clojure inherit it.

shenedu 14y ago

author here. > Notice that in his tests 97% of these connections don't do anything, just idle. He maxes out at 18764 req/sec. Yes, just testing how many concurrent connection can be held. When the 600k are held, ab confirms that it can do about 31405.53 per seconds, the http body is 1024bytes. > Notice that they are "keep-alived", coming from the same IP, so not truly separate connections Not from the same ip, from many ips: 192.168.1.200~230 > Keep in mind that 600K concurrent connections cannot possibly do anything useful at the same time for many reasons (CPU, bandwidth, server I/O), so they are not truly concurren They send a request every 5s~30s to server, and wait for response

rorrr 14y ago
> Not from the same ip, from many ips: 192.168.1.200~230 So from 31 IPs, which can be done with 31 keepalive connections. Try hitting your server with even 50K real connections and see how long it lasts (if it lasts at all). > They send a request every 5s~30s to server, and wait for response Exactly. ALL of them don't do anything concurrently, they just sit idly.
- alexkus 14y ago
  You seem to be missing the point of the scenario they're testing. Lots of idle connections (doing overlapping long polling) is exactly how many COMET servers work. We send ~60 "events" via our COMET server (APE from www.ape-project.org) in a typical 2 hour period. The server side work to decide when/what to send the clients is easy because it's the same information that gets sent whether there is 1 connection or 1,000,000. The fact they're from just 31 different IP addresses isn't relevant. They're still individual connections from clients to the end server.
  - rorrr 14y ago
    > The fact they're from just 31 different IP addresses isn't relevant. They're still individual connections from clients to the end server. That's where you are wrong. Not only they are keepalive connections, they are completely local. Do it over an actual network from 50K different IPs and see how that performs.

jlouis 14y ago

I want to make an important point on 3) If you have 600K concurrent connections they are concurrent. You could have them on a single core, limited severely on bandwidth and disk I/O. What you don't have is parallelism, since they are not executing at the same time. I feel that this distinction is important to make. That most of them are waiting on a given event to happen does not make it any less concurrent, but it does limit the amount of parallelism which is possible. On a single core machine, the operating system is concurrently executing processes, perhaps a hundred of those. But only one process can be on the CPU at a time, so the parallelism count is always either 0 or 1.