I’m wondering whether Unicorn is the right webserver for us. Reading up on it (here) it is notoriously slow for slow clients, “while downloading the request off the socket, Unicorn workers cannot accept any new connections, and that worker becomes unavailable.” This perhaps fits with something I noticed looking into the Order cycle page hanging, that one of the gems fires off a request to an external API and we see the whole page hang waiting for this API that often didn’t respond.
Perhaps in the UK we just need more workers as our servers are pretty overspecced for our load, we should be able to handle more than it seems we can.
Not sure how much work is involved in updating the webserver. Probably a lot.
But given that in the UK context I can really see us having a high number of slow clients we might want to look into this. Looks like a better solution for us might be Puma, which we can scale up to clustered when we grow to a size that warrants it…
But your quote about Unicorn being blocked on slow clients happens in a Unicorn-only setup. Since we use nginx in front of Unicorn, that should handle the slow requests. Same post:
You can use nginx in a custom setup to buffer requests to Unicorn, eliminating the slow-client issue.
So I guess that is what’s happening. Did you compare your queue time and application response time on New Relic? That should answer the question if there is a bottle neck in queue time.
The above statement is confirmed in the conclusion of that post:
Choose a multi-process web server with slow client protection and smart routing/pooling. Currently, your only choices are Puma (in clustered mode), Unicorn with an nginx frontend, or Phusion Passenger 5.
Puma would be an alternative solution, but our current setup should do as well. The remaining question is just if our setup is really doing the right thing. @RohanM, do you know?
From what I read and with all the problems we are having regarding long requests to generate reports for example, I think we should switch to a multithreaded webserver: Puma…
In my experience, reports are slow because they need to compute a lot. Our CPU is very busy and additional threads don’t give us more capacity. Multi-threading is useful if we have IO waits, for example if our SQL was efficient and it was only slow on reading the data form disk.
Threads can also save memory which could make our servers cheaper. But we should first make sure that our app is stable with many unicorn workers before we introduce many threads. Last time we went up to 7 workers, we got nasty errors on checkout.
In summary, I agree that Puma is the better solution but I see other work as more important and some of that work is a requirement before we can actually use Puma’s potential. Using preload_app with unicorn and increasing our worker count will take us a long way.
“Multi-threading is useful if we have IO waits” including DB queries. If a worker is waiting for SQL no other requests will be processed meanwhile, correct? This problem is solved by threads.
I think that switching to puma will make requests being served much faster while slow requests are being processed.
