Wybór serwera aplikacji dla API backend

Question

Przy tak wielu wyborów dla serwera aplikacji (pasażerski, cienki, Unicorn, Mongrela, Puma i Rainbows!), Zastanawiam się, co byłoby właściwe dla następujący scenariusz:

Rails jest używany wyłącznie do obsługi interfejsu API (wszystkie zasoby są obsługiwane przez Nginx). Niektóre wywołania API zależą od innych usług interfejsu API, więc czasami ich ukończenie zajmuje trochę czasu.

Aplikacja responsywna jest używana w telefonach komórkowych, tabletach i komputerach stacjonarnych, więc nie ma żadnych gwarancji dotyczących połączenia z klientem.

Jaki serwer aplikacji uważa Pan za odpowiedni w tym przypadku? Jakie rzeczy należy wziąć pod uwagę przy wyborze?

Answer 1

Jeśli twoja aplikacja wykonuje połączenia API z innymi usługami, to Unicorn to zły wybór. Unicorn to wielowątkowy serwer aplikacji o pojedynczym wątku, opracowany z myślą o szybkich, krótkotrwałych obciążeniach związanych z procesorem. Wykonywanie połączeń HTTP API jest długotrwałym blokowaniem żądań we/wy. To nie jest ograniczenie, ale wyraźny wybór projektu Jednorożca. Potwierdza to the Unicorn website, sekcja "Po prostu gorsza w niektórych przypadkach".

Teoretycznie Thin może obsłużyć takie obciążenia o wysokiej współbieżności, ponieważ wykorzystuje zdarzenie we/wy. Wymaga to jednak wyraźnego wsparcia w zakresie struktury i aplikacji w postaci zgłoszonego kodu. Nieliczne frameworki i aplikacje to robią. Railsy i Sinatra nie.

Pozostawia to tylko serwery aplikacji obsługujące wielowątkowość. Trzej rywale to Puma, Rainbows i Phusion Passenger 4 Enterprise.

• Puma jest stosunkowo nowa. Rainbows jest nieco starsza, ale autor nie daje żadnych gwarancji, czy to działa dobrze. Phusion Passenger jest dojrzały, istnieje od lat i jest obecnie używany przez ponad 150000 stron internetowych, w tym duże takie jak Pixar, New York Times, AirBnB itp.
• Modele użytkowania Puma i Rainbows są podobne do Unicorn i Thin w tym uruchamiasz szereg procesów i łączysz je z Nginx poprzez konfigurację odwrotnego proxy. Z kolei Phusion Passenger jest przeznaczony do bezpośredniej integracji z Nginx, więc wymaga znacznie mniej konfiguracji, zarządzania procesami i innych kosztów administracyjnych.
• Phusion Passenger 4 Enterprise nie jest serwerem wielowątkowym, ale hybrydowym wieloprocesorowym/wielowątkowym. Oznacza to, że może uruchomić wiele procesów (w celu zwiększenia stabilności i możliwości korzystania z wielu rdzeni procesora), z których każdy ma wiele wątków (dla dużej współbieżności we/wy).
• Fusion Passenger 4 Enterprise przynosi many advantages ma więcej funkcji niż Puma i Rainbows: na przykład ma poza zbieraniem śmieci, może dynamicznie dostosowywać liczbę procesów w oparciu o ruch, całkowicie automatyzuje ponowne uruchamianie, więc nie potrzebujesz skryptów itp.

Możesz również być zainteresowany this writeup, aby uzyskać więcej informacji.

Answer 2

Jedną Prawdziwą metodą poznania jest testowanie i mierzenie wyników w rzeczywistych warunkach. Wszystko inne będzie przypuszczeniami i domysłami.

W międzyczasie powinieneś zacząć od tego, o którym wiesz, że jest wystarczająco dobry (jednorożec wydaje się być dość popularnym i przyzwoitym wyborem) i radzić sobie z wydajnością serwera, gdy stanie się wąskim gardłem.

Answer 3

Na podstawie Twojego samodzielnego polecenia polecam serwer Puma lub Unicorn za odwrotnym proxy nginx. Użyj sidekiq dla kolejek roboczy. Zakłada się, że aplikacja Railsowa, jeśli używasz Sinatry, cienka może być wystarczająco dobra dla ciebie. Tak jak mówiła inna osoba, napisz najpierw o stabilności, a nie o wydajności testu.