Forcing Puma is a regression; please revert to the more stable unicorn
Based on the field experience of upgrading from a 12.7 unicorn installation to 14.1, my conclusion is that the obsolescence of Unicorn is premature and a huge error. I have no idea what (if any) engineering requirements were fulfilled by this move, but from my point of view, it's a bad one. Performance gains of multi-threading are moot given stability issues that are clearly unproven. Also, TBMI, Ruby still doesn't have a well-defined multi-process/forking model within a thread-based context. Which means deadlocks and race-conditions are not impossible.
Evidence:
-
a constant stream of errors appears in the error logs, of the form:
{"timestamp":"2021-08-09T13:55:04.656Z","pid":5381,"message":"PumaWorkerKiller: Out of memory. 2 workers consuming total: 2083.3828125 mb out of max: 2058.0 mb. Sending TERM to pid 5742 consuming 722.9921875 mb."}Note: 2GB is a lot more than the default as-provided and recommended default. WTF? -
The documentation of the WorkerKiller Gem makes it clear it is NOT TO BE USED IN PRODUCTION, assuming one has read the README. "Before you use this gem, know that it is dangerous. If you have a memory issue, you need to fix the issue. The original idea behind this gem is that it would act as a temporary band-aid to buy you time to allow you to fix your issues. If you turn this on and don't fix the underlying memory problems, then things will only get worse over time." Exactly.
-
WebIDE no longer works -- but this is not yet proven to be an issue with Puma.
A very lengthy and detailed investigation/ comparison between Puma and Unicorn showed that Unicorn had barely any significant performance advantage at all. The assessment indicated that Unicorn with 5 workers was generally better under the tested load scenarios than all Puma scenarios. Ironically, it was assumed/believed that Puma would result in better memory utilization.