Strange with keep-alive about facil.io HOT 6 CLOSED

Segfault - my mistake, iIdon't check on null body_string

from facil.io.

I'm a bit busy today, I'll try to be short and fast, if I don't answer everything, I'll write more when I can.

I think you encountered a known issue with the HTTP protocol that was probably (maybe) made worst because your previous code was writing directly to the sockets instead of using an http_response_s object (this object will optimize parts of the response and make sure it's formatted correctly).

One of the issues in the HTTP/1.1 protocol is that it is VERY expensive to open and close network connections. There's a whole lot of processing required by the kernel as well as a TCP/IP feature called "slow start".

It's even worst if the same client sends a lot of requests (requiring a lot of new connections). Each client has a "cool-down" period for each connection port (about two minutes on many systems) and there's a theoretical limit on how many connection ports each client can use (~64K ports per client for each listening socket)... This is system related, not much we can do about it.

This is a serious issue if you have many requests from a single client.

In normal HTTP settings, Keep Alive should improve performance drastically.

It's also why HTTP/1.1 is being replaced with HTTP/2, why Websockets are often used instead of AJAX and why memcache was using persistent connections instead of HTTP.

The better the server is designed (the server overhead is low), the higher the performance gain for Keep Alive (the more you notice the issue with the TCP/IP layer).

For facil.io, Keep-Alive should improve performance at a X20 rate (%2000)! This is similar to nagging and it's partly because facil.io is relatively fast with a small overhead. On other systems you might see smaller improvement (they have higher overhead).

HOWEVER, I suspect some of the delays were because of the way the old code you used in the test was handling response issue.

In the old code you wrote to the socket directly. This can cause HTTP errors in relation to the Content-Length header...

...When this happens, the client (curl) might wait for a disconnection before it realizes that the response is complete. Unless you manually close the socket, you are actually waiting for the HTTP timeout to occur (the default is 5-6 seconds).

...

from facil.io.

As to the segfault, I'm not sure where it's coming from.

However, would you mind experimenting with me?

If you add -DASYNC_USE_SENTINEL=1 to the CFLAGS in the makefile (or update the value in libasync.c), than the server will try to listen to error signals and it will try to recuperate after some errors without crashing. It will also print an error report with a backtrace of the stack, so you have more information about what happened.

from facil.io.

Oh, I just noticed you know what happened... forget about it :-)

from facil.io.

Thank you Boaz! Your code very well commended, i will read it!

from facil.io.

You're very welcome.

If you find that the keep-alive is slower than it should be or anything else, please let me know.

If there's anything wrong I would like to fix it. Having false alarms is better than not knowing :-)

Thank you for opening the issues.

from facil.io.