Who said nginx can only handle 10k connections? I’m pretty sure that is configurable…

Everyone is talking past each other here. Whether or not NGINX can respond to more regular HTTP requests per second than cowboy I don’t think is a useful metric. NGINX is very fast, nobody is disputing that.

However, the ability to get a new connection, reply quickly, and then drop it (regular HTTP) does not imply that it will hold several hundred thousand connections open indefinitely with reasonable RAM usage. Maybe it will! My point is simply that the wrk benchmark offers no evidence of that behaviour, because it doesn’t test that behaviour.

@NobbZ NGINX can definitely reverse proxy web socket connections, but I too don’t know about what the resource consumption of doing so is.

All in all it’s a good question, although notably you could just cut NGINX out of the picture entirely by not using a reverse proxy. For our production servers for example we just run cowboy on 8080, and then the AWS load balancer routes port 80 traffic to 8080.

wrk is known to have problems with cowboy and applications based on that.

Running the tool to measure on the same host as the thing you measure is a bad idea as well.

My understanding is that Cowboy can handle 2 million concurrent connections on a single server – using very powerful but still commercially available hardware.

Of course, connections aren’t everything, and there’s matters such as database storage and access speed that in the real world would be likely to take precedence at that sort of scale.

And therefore irrelevant in this discussion.

Because of the issues between wrk and cowboy this not-test doesn’t even show an order of magnitude. It just confirms that wrk and cowboy don’t play well.

The real benchmark that had to be done to answer the original question, is one that stresses a reverse-proxying nginx to an phoenix application.

Also we have to remember that the 2M for phoenix are establish websocket connections, while those 10k connections for cowboy probably are meant as concurrent requests that need to be handled by it. Serving files and stuff. I’m not sure how we can compare those.

I’m not sure how websocket connections which are only passed through via reverse-proxy do affect the ability to handle further incomming requests of NGINX. I’m not even sure if we can reverse-proxy Websocket connections.

You are really talking about the wrong things here.