Dlaczego Unicorn musi być wdrożony razem z Nginx?

Nginx jest czystym serwerem WWW, który jest przeznaczony do serwowania statycznej zawartości i / lub przekierowywania żądania do innego gniazda, aby obsłużyć żądanie.

Unicorn jest serwerem sieciowym Typu Rack i jest przeznaczony tylko do hostowania aplikacji typu Rack, która zazwyczaj generuje dynamiczną zawartość. Aplikacje Rack mogą również obsługiwać statyczne treści, ale są mniej wydajne niż większość innych tradycyjnych serwerów internetowych.

Większość konfiguracji RoR używa kombinacji zarówno tradycyjnych serwerów internetowych, jak i serwerów Rack, aby zastosować najlepsze obu ich możliwości. Nginx jest niesamowicie szybkim przekierowaniem na żądanie poprzez równoważenie proxy i serwowanie statycznej treści. Unicorn jest w stanie przetwarzać nagłówki HTTP i równoważyć przychodzące żądania do Ruby w celu przetworzenia.

Ta odpowiedź jest komplementarna do innych i wyjaśnia Dlaczego Unicorn potrzebuje nginxa przed sobą .

[1]}TL;DR powodem, dla którego Unicorn jest zwykle wdrażany razem z odwrotnym serwerem proxy, takim jak nginx, jest to, że jego twórcy celowo tak go zaprojektowali, tworząc kompromis dla prostoty. Po pierwsze, nic nie powstrzyma cię przed wdrożeniem Unicorn Bez odwrotnego serwera proxy. Jednak nie byłby to zbyt dobry pomysł; zobaczmy dlaczego. Unicorn podąża za filozofią Uniksa, która polega na tym, aby robić jedną rzecz i robić to dobrze, a mianowicie, aby obsługiwać szybkich klientów o niskim opóźnieniu (zobaczymy, co to oznacza później). Fakt, że Unicorn jest przeznaczony dla szybkich klientów o niskim opóźnieniu również sugeruje, że nie jest zbyt dobry dla wolnych klientów o wysokim opóźnieniu , co jest prawdą. Jest to jeden ze słabych punktów Unicorna i to tam w grę wchodzi odwrotne proxy: siedzi przed Unicornem i zabiera opieka nad tymi powolnymi klientami (zobaczymy Jak później).

Na szczęście taki odwrotny proxy już istnieje i nazywa się nginx .

Decyzja o obsłudze tylko szybkich klientów, znacznie upraszcza projekt Unicorn i pozwala na znacznie prostsze i mniejsze bazy kodowej, kosztem dodatkowej złożoności działu wdrożeń (tj. musisz wdrożyć nginx też oprócz jednorożca).

Alternatywną decyzją może być zaprojektowanie jednorożca w w taki sposób, że nie będzie potrzebował odwrotnego proxy. Oznacza to jednak, że musiałby zaimplementować dodatkową funkcjonalność, aby zrobić wszystkie rzeczy, które teraz robi nginx, co skutkuje bardziej złożoną bazą kodową i większymi wysiłkami inżynierskimi.

Zamiast tego jego twórcy podjęli decyzję, aby wykorzystać istniejące oprogramowanie, które jest Przetestowane w boju i bardzo dobrze zaprojektowane, i aby uniknąć marnowania czasu i energii na problemy już rozwiązane przez inne oprogramowanie.

Ale bądźmy techniczni i odpowiedzmy na twoje pytanie:

Dlaczego Unicorn musi być wdrożony razem z nginx?

Oto niektóre z kluczowych powodów:

Unicorn używa blokowania I / O dla klientów

Poleganie na odwrotnym proxy oznacza, że Unicorn nie musi używać nieblokujących We/Wy.zamiast tego może używać blokowania We/Wy, co jest z natury prostsze i łatwiejsze do naśladowania dla programisty.

Również jakoprojekt dokument stwierdza:

[Używanie blokowania We / Wy] pozwala na prostszą ścieżkę kodu wewnątrz interpretera Ruby i mniej syscalli.

Jednak ma to również pewne konsekwencje:]} Kluczowy punkt # 1: Jednorożec nie jest wydajny z powolnymi klientami]}

(dla uproszczenia Zakładamy konfigurację z 1 robotnikiem jednorożca)

Ponieważ blokowanie I/O jest używane, pracownik Unicorn może obsługiwać tylko jednego klienta na raz , więc wolny klient (tj. jeden z powolnym połączeniem) skutecznie utrzymywałby pracownika zajętego przez dłuższy czas (niż zrobiłby to szybki klient). W międzyczasie inni klienci będą po prostu czekać, aż pracownik będzie wolny ponownie (tj. żądania będą piętrzyły się w kolejce).

Aby obejść ten problem, przed Unicornem jest wdrożony odwrotny serwer proxy, który w pełni buforuje przychodzące żądania i aplikacja odpowiada, a następnie wysyła każde z nich na raz (aka spoon-feeds them) do Unicorn i klientów, odpowiednio. W związku z tym można powiedzieć, że reverse proxy "chroni" jednorożca przed wolnymi klientami sieciowymi.

Na szczęście Nginx jest świetnym kandydatem do tej roli, ponieważ został zaprojektowany, aby efektywnie obsługiwać tysiące setek jednoczesnych klientów.

Kluczowe znaczenie ma to, aby odwrotne proxy znajdowały się w tej samej sieci lokalnej co Unicorn (zazwyczaj na tej samej fizycznej maszynie komunikującej się w/ Unicorn przez gniazdo domeny uniksowej), tak aby opóźnienie sieci było ograniczone do minimum.

Więc taki proxy skutecznie pełni rolę szybkiego klienta , który Unicorn został zaprojektowany do obsługi w pierwszej kolejności, ponieważ proxy wysyła żądania do Unicorn szybkiego i utrzymuje pracowników zajętych przez jak najkrótszy czas (w porównaniu do tego, ile czasu zrobiłby klient z wolnym połączeniem).

Klucz #2: Unicorn nie obsługuje HTTP / 1.1 keep-alive

Ponieważ Unicorn używa blokowania We/Wy, oznacza to również, że nie może obsługiwać funkcji HTTP/1.1 keep-alive, ponieważ trwałe połączenia powolnych klientów szybko zajmowałyby wszystkich dostępnych pracowników.

Dlatego aby wykorzystać http keep-alive, zgadnij co: używany jest odwrotny serwer proxy.

Nginx z drugiej strony, może obsługiwać tysiące jednoczesnych połączeń za pomocą kilku wątków. W związku z tym nie ma ograniczeń współbieżności serwera takiego jak Unicorn (które zasadniczo ograniczają się do ilości procesów roboczych), co oznacza, że może obsługiwać trwałe połączenia dobrze. Więcej jak to działa można znaleźć tutaj .

Dlatego nginx akceptuje połączenia keep-alive od klientów i proxy je do Unicorn poprzez zwykłe połączenia poprzez typowo Gniazdo Unix.

Punkt # 3: Unicorn nie jest zbyt dobry w serwowaniu plików statycznych

Ponownie, serwowanie plików statycznych jest rzeczą, którą Unicorn Może robić, ale nie jest zaprojektowana do tego, aby robić wydajnie.

Z drugiej strony, odwrotne proxy, takie jak nginx, są w tym znacznie lepsze (tj. sendfile(2) & buforowanie).

Więcej

Istnieją inne punkty, które są opisane w filozofia dokument (zobacz "Poprawa wydajności poprzez odwrotne proxy" ).

[1]}Zobacz także niektóre z podstawowych funkcji nginx .

Widzimy, że wykorzystując istniejące oprogramowanie (np. nginx) i zgodnie z filozofią Uniksa "Robienie jednej rzeczy i robienie tego dobrze", Unicorn jest w stanie podążać za prostszym projektem i implementacją, zachowując przy tym bądź wydajny w obsłudze aplikacji Rack (np. Twoja aplikacja Rails).

[1]}Aby uzyskać więcej informacji, zapoznaj się z filozofią Unicorn i projekt dokumenty, które wyjaśniają bardziej szczegółowo wybory stojące za projektem Unicorn i dlaczego nginx jest uważany za dobry odwrotny proxy dla Unicorn.

Nginx może być używany do obsługi wolnych klientów na serwerze unicorn, ponieważ powolni klienci dławiliby serwer unicorn. Nginx jest używany jako pewnego rodzaju serwer proxy buforujący wszystkie żądania i odpowiedzi do powolnych klientów.

Zobacz http://unicorn.bogomips.org/