7 ms·

Show HN: Hellepoll is a blazingly-fast async HTTP server written in C++

35 points by willvarfar 15y ago

This is based on an approach I made for a very high performance message and video multiplexing server. The project died, but I'm glad I get to share the a basic version with some http test code now. I admit this is the second time I've tried to show this off here today; I posted earlier but it got lost when no-one was watching :(

tewks 15y ago
I'm curious as to why the author hasn't referenced nginx, which is written also event based (epoll/kqueue) and written in C.
- willvarfar 15y ago
  I've used nginx a lot. So I guess that's why I don't see the overlap. Nginx is not tornado in c. Its not about complex custom logic, its about rules redirects and caching.
- givan 15y ago
  Probably because is much slower than nginx, C++ adds extra "fat" that nginx (writen in C) doesn't have.
  - apaprocki 15y ago
    Not sure that matters much.. the code style is very C/C++. (e.g. using stdio instead of iostreams, malloc/free instead of new/delete, no STL)
  - swah 15y ago
    If its faster than nginx, Igor just removes some sleep() calls.
  - sigil 15y ago
    Not sure about C++ overhead there. C++ often edges out C in the alioth benchmarks. More to the point, I highly doubt the author's parser ("parser") in http.cpp is faster than the one in nginx, which really is a thing of beauty. http://trac.nginx.org/nginx/browser/nginx/trunk/src/http/ngx_http_parse.c http://trac.nginx.org/nginx/browser/nginx/trunk/src/http/ngx...
    - swah 15y ago
      This is so verbose, it must have been rewritten for performance so many times :)
    - kingkilr 15y ago
      I really love the trick for efficiently reading 4 chars and checking them out of a string. I like it so much I've been working towards making it happen automatically on PyPy so if you write something like: if buf[i:i+4] == "POST": the JIT automatically turns that into a MOVL + CMP + JMP. The magic of high level languages :)
WALoeIII 15y ago
I immediately wanted to fork this and have it just return "Allan!" instead of "Hello World". http://www.youtube.com/watch?v=xaPepCVepCg http://www.youtube.com/watch?v=xaPepCVepCg
apaprocki 15y ago
You should not be #include-ing headers inside of an extern "C" block. It is up to those headers to: #ifdef __cplusplus extern "C" { #endif
- humbledrone 15y ago
  And, if those headers do not already wrap themselves in their own extern "C" block, wrapping around the #include is sometimes a quick fix (e.g. until the upstream authors merge your pull request).
  - DiabloD3 15y ago
    This. Windows porters frequently have to do this to deal with the fact Microsoft still refuses to produce a C compiler, and instead just does double duty on their existing C++ compiler.
- CamperBob 15y ago
  Um, OK, I'll bite. Why not?
kqueue 15y ago
I believe you are testing the requests / sec and not replies / sec. While requests / sec matters a bit, you'll most probably be bottle-necking in your context switches. What matters is replies / sec. This is a more accurate measurement of your server performance and not OS bottlenecks. I'd use httperf for this matter.
- willvarfar 15y ago
  I am confused. What context switches?
  - kqueue 15y ago
    Measuring requests per second is close to measuring the number of accept system calls you can do. Since it's a system call you have a context switch.
    - jerf 15y ago
      I would love to see "someone" do that benchmark; using epoll, accept as many sockets as possible, for the sake of argument let's stuff one byte down them, and then properly shut them down. I'm curious how close to the limit of the underlying poll technology we're getting, because it seems like everyone is converging in roughly the same area, in an order-of-magnitude sense. I also find myself wondering about the implications of these artificial benchmarks and the stuff Zed discussed here: http://sheddingbikes.com/posts/1280829388.html http://sheddingbikes.com/posts/1280829388.html
      - kqueue 15y ago
        request rate is not influenced much by the polling mechanism (epoll/kqueue/poll/select) when all you're doing is listening to one fd and processing new ones then closing then immediately. These multiplexers matter when you are working on lots of file descriptors. It matters because select will have to iterate over all the file descriptors you passed to it, while kqueue for example have knotes registered to it when it wakes up and won't need to iterate over everything, but just the knotes it got. Not to mention the data copying from userland to the kernel in case of select/poll. Back to the request rate limitations, the limitation is mainly coming from the # of system calls you can execute in a sec (accept() in this case) which is heavily influenced by the context switches. Looking at the application CPU gives you a very good idea of what your bottleneck is. If your CPU is 100% then it's clear your application is hitting the limit, but if the application CPU is at 30% and you cannot process more requests / sec then you've hit the system limit here.
k33n 15y ago
Cool stuff. I assume you wrote this for your own personal gratification and not to compete with Nginx or something. What was the coolest thing you learned in putting this together?
enduser 15y ago
ULib is a mature and well-considered C++ framework for developing high-performance applications that includes a blazingly-fast async HTTP server--more batteries included. https://github.com/stefanocasazza/ULib https://github.com/stefanocasazza/ULib
pilooch 15y ago
How does it compare to libevent evhttp server? Besides being written in C++...

35 points by willvarfar 15y ago

tewks 15y ago

I'm curious as to why the author hasn't referenced nginx, which is written also event based (epoll/kqueue) and written in C.

willvarfar 15y ago
I've used nginx a lot. So I guess that's why I don't see the overlap. Nginx is not tornado in c. Its not about complex custom logic, its about rules redirects and caching.
givan 15y ago
Probably because is much slower than nginx, C++ adds extra "fat" that nginx (writen in C) doesn't have.
- apaprocki 15y ago
  Not sure that matters much.. the code style is very C/C++. (e.g. using stdio instead of iostreams, malloc/free instead of new/delete, no STL)
- swah 15y ago
  If its faster than nginx, Igor just removes some sleep() calls.
- sigil 15y ago
  Not sure about C++ overhead there. C++ often edges out C in the alioth benchmarks. More to the point, I highly doubt the author's parser ("parser") in http.cpp is faster than the one in nginx, which really is a thing of beauty. http://trac.nginx.org/nginx/browser/nginx/trunk/src/http/ngx_http_parse.c http://trac.nginx.org/nginx/browser/nginx/trunk/src/http/ngx...
  - swah 15y ago
    This is so verbose, it must have been rewritten for performance so many times :)
  - kingkilr 15y ago
    I really love the trick for efficiently reading 4 chars and checking them out of a string. I like it so much I've been working towards making it happen automatically on PyPy so if you write something like: if buf[i:i+4] == "POST": the JIT automatically turns that into a MOVL + CMP + JMP. The magic of high level languages :)

WALoeIII 15y ago

I immediately wanted to fork this and have it just return "Allan!" instead of "Hello World". http://www.youtube.com/watch?v=xaPepCVepCg http://www.youtube.com/watch?v=xaPepCVepCg

apaprocki 15y ago

You should not be #include-ing headers inside of an extern "C" block. It is up to those headers to: #ifdef __cplusplus extern "C" { #endif

humbledrone 15y ago
And, if those headers do not already wrap themselves in their own extern "C" block, wrapping around the #include is sometimes a quick fix (e.g. until the upstream authors merge your pull request).
- DiabloD3 15y ago
  This. Windows porters frequently have to do this to deal with the fact Microsoft still refuses to produce a C compiler, and instead just does double duty on their existing C++ compiler.
CamperBob 15y ago
Um, OK, I'll bite. Why not?

kqueue 15y ago

I believe you are testing the requests / sec and not replies / sec. While requests / sec matters a bit, you'll most probably be bottle-necking in your context switches. What matters is replies / sec. This is a more accurate measurement of your server performance and not OS bottlenecks. I'd use httperf for this matter.

willvarfar 15y ago
I am confused. What context switches?
- kqueue 15y ago
  Measuring requests per second is close to measuring the number of accept system calls you can do. Since it's a system call you have a context switch.
  - jerf 15y ago
    I would love to see "someone" do that benchmark; using epoll, accept as many sockets as possible, for the sake of argument let's stuff one byte down them, and then properly shut them down. I'm curious how close to the limit of the underlying poll technology we're getting, because it seems like everyone is converging in roughly the same area, in an order-of-magnitude sense. I also find myself wondering about the implications of these artificial benchmarks and the stuff Zed discussed here: http://sheddingbikes.com/posts/1280829388.html http://sheddingbikes.com/posts/1280829388.html
    - kqueue 15y ago
      request rate is not influenced much by the polling mechanism (epoll/kqueue/poll/select) when all you're doing is listening to one fd and processing new ones then closing then immediately. These multiplexers matter when you are working on lots of file descriptors. It matters because select will have to iterate over all the file descriptors you passed to it, while kqueue for example have knotes registered to it when it wakes up and won't need to iterate over everything, but just the knotes it got. Not to mention the data copying from userland to the kernel in case of select/poll. Back to the request rate limitations, the limitation is mainly coming from the # of system calls you can execute in a sec (accept() in this case) which is heavily influenced by the context switches. Looking at the application CPU gives you a very good idea of what your bottleneck is. If your CPU is 100% then it's clear your application is hitting the limit, but if the application CPU is at 30% and you cannot process more requests / sec then you've hit the system limit here.

k33n 15y ago

Cool stuff. I assume you wrote this for your own personal gratification and not to compete with Nginx or something. What was the coolest thing you learned in putting this together?

enduser 15y ago

ULib is a mature and well-considered C++ framework for developing high-performance applications that includes a blazingly-fast async HTTP server--more batteries included. https://github.com/stefanocasazza/ULib https://github.com/stefanocasazza/ULib

pilooch 15y ago

How does it compare to libevent evhttp server? Besides being written in C++...