3 ms·

Yeah, libevent with http support scales crazy. I did a 4-5k req per second demo application last year. It took me about 25 minutes to write it (that was what sh

by alecco 18y ago

Yeah, libevent with http support scales crazy. I did a 4-5k req per second demo application last year. It took me about 25 minutes to write it (that was what shocked me most.) Also a libevent server would probably fit the L1 cache. The data might fit in L2 depending of a function of overall throughput, message sizes, and of course the size of the L2 :)

gcv 18y ago
Very interesting. A couple of questions for you, in no particular order. 1. Have you used libev? I read that it's comparable, and in some ways superior to libevent, but I'm not sure why. I haven't found much documentation, though. Do you know if it also has some kind of HTTP server built in? 2. If I understand libevent correctly, it just uses a highly efficient mechanism to watch the file descriptor corresponding to a server socket (epoll, kqueue), and when data comes in on the socket, it runs a handler. If the handler is small and efficient, then in theory it will run faster than code which has several listener threads because thread context switches take time, and because it becomes more difficult to take advantage of the CPU's cache. Is this really still true in e.g., recent Linux kernels with NPTL? Also, would you run two libevent app instances on a two-core CPU?
- davidw 18y ago
  Where Erlang really shines in all this is that they also have a scheduler built into the system, so that you can handle "long running calculations" without 1) blocking the whole thing up, or 2) having to use threads.
- alecco 18y ago
  1. No experience on livev, only libevent. 2. libevent is an abstraction layer providing a single API for many event based subsystems. So you can write ANSI/POSIX C code with it portable and at the maximum available event i/o layer. I doubt any implementation on NPTL or any threading mechanism can get close in performance to this. The overhead of managing threads is big. About multiple cores, I don't think it is necessary. The CPU work should be minimal. If there is something else you need to do as backend, maybe it can be on a separate process and use fast inter process communication, say sharing memory (rfork is a good start, for example.)

by alecco 18y ago

gcv 18y ago

Very interesting. A couple of questions for you, in no particular order. 1. Have you used libev? I read that it's comparable, and in some ways superior to libevent, but I'm not sure why. I haven't found much documentation, though. Do you know if it also has some kind of HTTP server built in? 2. If I understand libevent correctly, it just uses a highly efficient mechanism to watch the file descriptor corresponding to a server socket (epoll, kqueue), and when data comes in on the socket, it runs a handler. If the handler is small and efficient, then in theory it will run faster than code which has several listener threads because thread context switches take time, and because it becomes more difficult to take advantage of the CPU's cache. Is this really still true in e.g., recent Linux kernels with NPTL? Also, would you run two libevent app instances on a two-core CPU?

davidw 18y ago
Where Erlang really shines in all this is that they also have a scheduler built into the system, so that you can handle "long running calculations" without 1) blocking the whole thing up, or 2) having to use threads.
alecco 18y ago
1. No experience on livev, only libevent. 2. libevent is an abstraction layer providing a single API for many event based subsystems. So you can write ANSI/POSIX C code with it portable and at the maximum available event i/o layer. I doubt any implementation on NPTL or any threading mechanism can get close in performance to this. The overhead of managing threads is big. About multiple cores, I don't think it is necessary. The CPU work should be minimal. If there is something else you need to do as backend, maybe it can be on a separate process and use fast inter process communication, say sharing memory (rfork is a good start, for example.)