Rekomendacje (i różnice) pomiędzy różnymi serwerami produkcyjnymi Ruby on Rails
Wkrótce planuję wdrożyć moją pierwszą aplikację Ruby on Rails w środowisku produkcyjnym i wybrałem nawet webhost z całym zarządzanym serwerem i dobrocią Capistrano, jakiej można oczekiwać od dostawcy RoR.
Dostawca pozwala na Serwery WWW Kundel, Thin, Passenger & FastCGI, które wydają się bardzo elastyczne, ale szczerze mówiąc nie znam różnic między nimi. Przyjrzałem się im trochę, ale wszystko robi się trochę dużo, gdy zaczynają mówić o funkcjach i maksymalnym jednoczesne żądania - i że te dane wydają się różnić w zależności od tego, kto je publikuje.
Spojrzałem na Passenger (na powierzchni) - co wydaje mi się bardzo atrakcyjne - ale miałem wrażenie, że Passenger nie był faktycznym serwerem internetowym, a zamiast tego był bardziej jak warstwa na Apache lub nginx i zarządzał zrodzonymi instancjami aplikacji (jak klaster Kundli).
Czy ktoś mógłby mi wyjaśnić różnice w pojęciach laika, tak abym mógł wybierz mądrze (bo każdy, kto widział [7]} Indianę Jonesa i ostatnią krucjatę [8]} wie, co się stanie, jeśli wybierzesz źle).
4 answers
Krótka odpowiedź
Idź z Apache / Nginx + pasażer. Pasażer jest szybki , niezawodny, łatwy w konfiguracji i wdrożeniu. Pasażerowie zostali przyjęci przez dużą liczbę aplikacji dużych szyn, w tym Shopify .
Alt text http://www.modrails.com/images/passenger_mongrel_thin_benchmark.png
Długa odpowiedź
Zapomnij o CGI i FastCGI. Na początku nie było innych alternatyw, więc jedynym sposobem, aby uruchomić Rails korzystał z CGI lub szybszej przeglądarki FastCGI. Obecnie prawie nikt nie jeździ szynami pod CGI. Najnowsze wersje Rails nie są już dostępne .cgi i .biegacze fcgi.
Kundel był w dużej mierze przyjętym rozwiązaniem, najlepszym zamiennikiem CGI i FCGI. Wiele obiektów nadal korzysta z klastra Kundel i Kundel, jednak projekt Kundel jest prawie martwy, a wiele projektów zostało już przeniesionych na inne rozwiązania (głównie pasażerskie). Również architektura oparta na kundlu jest dość trudna do skonfigurowania, ponieważ wymaga interfejs proxy (thin, ngnix) i architektura backendowa złożona z wielu instancji.
Passenger zyskuje na popularności odkąd został wydany. Wiele projektów zmieniło się z Kundla na pasażera z wielu powodów, w tym (ale nie wyłącznie) łatwego wdrażania, łatwości konserwacji i wydajności. Dodatkowo Pasażer jest teraz dostępny zarówno dla Apache, jak i Ngnix.
Najprostszym sposobem użycia Passenger jest konfiguracja Apache + Passenger. Jeden Apacz instalacja i wiele procesów pasażerskich.
Jeśli potrzebujesz lepszej wydajności i skalowalności, możesz użyć Ngnix jako frontendowego proxy i przesłać wszystkie żądania Rails do wielu serwerów backendowych, z których każdy składa się z Apache + Passenger. Nie wdaję się tutaj w szczegóły techniczne, To rozwiązanie ma być wykorzystywane przez projekty Rails o wysokim natężeniu ruchu.
Jeszcze bardziej złożone rozwiązania obejmują kombinację różnych poziomów, w tym proxy http i serwery. Ty może mieć pojęcie o tym, o czym mówię, czytając niektóre wewnętrzne szczegóły z GitHub i Heroku .
W tej chwili Passenger jest najlepszą odpowiedzią na większość projektów Rails.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2011-02-27 02:24:46
Mongrel i Thin to pojedyncze serwery procesów ruby, których wiele można uruchomić jako klaster za jakimś typem proxy(jak Apache lub Nginx). Proxy będzie zarządzać, które wystąpienie Kundel lub cienkie usługi żądania.
Passenger tworzy interfejs między Apache lub Nginx, który tworzy proces spawania aplikacji, a następnie forksuje procesy do serwera przychodzących żądań, gdy przychodzą. Istnieje wiele opcji konfiguracji, jak długo te procesy działają, ile może być i ile próśb będą służyć przed śmiercią. Jest to zdecydowanie najczęstszy sposób skalowania i obsługi aplikacji o dużym natężeniu ruchu, ale nie jest on pozbawiony wad. Można to zrobić tylko na systemie operacyjnym *nix (linux, mac os X, itp.). Ponadto procesy te kręcą się na żądanie, więc jeśli nikt nie uzyska dostępu do twojej witryny przez jakiś czas, proces ten umiera, a kolejne żądanie ma opóźnienie ponownego uruchomienia. Z Kundel i cienki, Proces jest zawsze uruchomiony. Czasami jednak nowe i świeże procesy mogą być dobre dla wykorzystania pamięci itp.
Jeśli ma to być witryna o stosunkowo niskim natężeniu ruchu, Mongrel or Thin zapewnia prosty, łatwy w zarządzaniu sposób wdrożenia aplikacji. Dla miejsc o większym natężeniu ruchu, gdzie potrzebujesz inteligentnego kolejkowania i zarządzania procesami czegoś takiego jak pasażer, jest to bardzo dobre rozwiązanie.
Jeśli chodzi o fastcgi, prawdopodobnie chcesz użyć tego jako ostatniej opcji.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-11-13 12:57:13
Używam Passenger + nginx. To działa naprawdę, naprawdę dobrze.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-11-13 15:15:21
Aby uzyskać natychmiastową wydajność, polecam użycie ruby enterprise edition.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-11-13 18:43:46