Allow working without cowboy_listener

[oribrost]

It seems like cowboy_listener offers two features:

• max conn limit
• protocol upgrades

Is it possible to add a flag to cowboy that allows disabling usage of cowboy_listener in cowboy_acceptor, as losing the two features above might be worth not having all acceptors doing gen_server calls to the cowboy_listener singletons. Note that it may possible to approximate max connection limit by enforcing it per acceptor instead.

@nivertech

[oribrost]

We implemented this in cowboy_acceptor.erl in nivertech@9e087b8

[ghost]

Hi!

I've toyed with the idea of separating the protocol options upgrades and connection limiting in cowboy_listener into two process types. Leaving the listener server responsible for only the protocol upgrades and using a cowboy_poolmon server for each acceptor process to enforce the connection limit. The benchmarks I performed on it indicated that this approach results in a slight improvement in response times when testing the maximum throughput using a larger number of short lived connections. It still needs more tuning and testing before I will even consider trying to convince @essen to include it in the master branch.

https://github.com/klaar/cowboy/compare/pool-monitors

Both me and @essen agree that a replacement for cowboy_listener server must be noticeably better than the current solution which has the benefit of being the simplest thing that can possibly work. At the moment there just aren't any hard numbers available to make replacing it a high priority item.

[ghost]

To be clear, the main issue with the current cowboy_listener is that the acceptor must perform a synchronous call after it has accepted the connection. Adding the delay this causes to the time it takes to process a connection. If we did it after the socket had been handed off to the request process the priority of this task wouldn't matter as much.

[essen]

Thanks for the links. It'll take a while to review and discuss all this though.

[essen]

I have done an experimental branch of a modification I've been wanting to do for a long time. Using async acceptors we do not need a call anymore, it can all be cast, and the listener can have greater control over the acceptors by sending messages directly to them.

https://github.com/essen/cowboy/tree/async-accept

In your case though, you probably want to disable the listener process entirely, in which case I'd just recommend to maintain a fork with the few direct calls removed. You're a very special case on that one so I'm not sure it really warrants adding and supporting another option. I'm not convinced either way yet though.

[ghost]

Ok, lets try to summarize my main reservations against including the current version of the async-accept branch. I produced a small wall of text on IRC, but it's good to have a copy here as well. Let's keep it brief.

The add_connection | suspend | resume protocol that is used to insert new connections into the pool and provide feedback to the acceptors is inaccurate and does not provide any backforce to throttle acceptor processes when the listener server cannot keep up. The scenario we want to avoid here is.

acceptors: accepts connections, casts to listener server
acceptors: continues to accept connections
listener: receives casts from acceptors, sends suspend to acceptors
before the suspend message is received, any number of connections may have been accepted.

Starting the connection handling process before a connection has been accepted also breaks the current behavior of the cowboy:accept_ack/1 function. The current behavior is that this function will return almost instantly because it is only used to await control of a socket that has already been accepted. With these changes applied, calls may block indefinitely. Users might as well start up workers and call Transport:accept with a timeout value of infinity directly from their code.

[essen]

To be continued in Ranch! Thanks. ninenines/ranch#6