Witajcie.
Poszukuję jakichś informacji na temat możliwie optymalnej konfiguracji serwera dedykowanego do korzystania z railsów(ew. merba,ale to tak naprawdę wszystko jedno).
Nie proszę o jakiś poradnik “za rączkę” jak na maszynie postawić railsy.
Co najlepiej wykorzystać? ruby enterprise edition z passengerem + nginx, czy może coś innego?
Jak z wydajnością JRuby?
Niezwykle cenne będą porady/uwagi osób, które korzystają z dedyków na codzień (jzabiello?) - poza samymi uwagami z czego budować taką platformę liczę na wszelkie uwagi/ciekawostki/hinty odnośnie uruchomienia i administracji takim projektem.
[quote=krzyzak]Witajcie.
Poszukuję jakichś informacji na temat możliwie optymalnej konfiguracji serwera dedykowanego do korzystania z railsów(ew. merba,ale to tak naprawdę wszystko jedno).
Nie proszę o jakiś poradnik “za rączkę” jak na maszynie postawić railsy.
Co najlepiej wykorzystać? ruby enterprise edition z passengerem + nginx, czy może coś innego?
Jak z wydajnością JRuby?
Niezwykle cenne będą porady/uwagi osób, które korzystają z dedyków na codzień (jzabiello?) - poza samymi uwagami z czego budować taką platformę liczę na wszelkie uwagi/ciekawostki/hinty odnośnie uruchomienia i administracji takim projektem.[/quote]
Obecnie najlepszy/najłatwiejszy w użyciu jest passenger. Jeżeli chodzi o wybór nginx/apache, to chyba bardziej kwestia upodobań i zastosowania (np. jeżeli masz dużo rzeczy korzystających z .htaccess, to na nginxie będzie Ci ciężko).
Jeżeli chodzi o jruby, to na pewno jest szybszy od MRI. Jeżeli możesz przerzucić aplikację na jruby, to spróbuj i zobacz jak to wychodzi wydajnościowo (bo nie na każdej aplikacji będzie widać duże różnice). Najłatwiejszy do skonfigurowania będzie pewnie nginx jako proxy + glassfishgem.
Co do samego serwera. Jeżeli zdecydujesz się na dedyka, to radzę Ci skonfigurować go używając chefa. Nie ma później sensu tracić czasu na konfigurację maszyny, gdy będziesz musiał zmienić serwer.
Jeżeli chodzi o dedyki. Uważaj na systemy preinstalowane. Na ovh na przykład są to jakieś stare wersje z podmienionymi repozytoriami, na których później często trzeba się namęczyć.
Nie mamy praktyki z JRuby. Natomiast REE sprawuje się bardzo dobrze bez względu na użyty serwer. W tej chwili mamy działających kilka ustawień:
nginx/mongrel - najprostsze w ustawieniu, jedynym potencjalnym problemem są umierające mongrele przy dużym ruchu
nginx/thin - stabilniejsze: thin nie ma tendencji do umierania
apache/passenger - działa, prosty w utrzymaniu, przysporzył nam nieco kłopotów na początku bo łatwo go źle skonfigurować
nginx/unicorn - równie prosty w ustawieniu jak mongrel, mniej kłopotliwe zarządzanie aplikacją niż w przypadku mongreli (start/restart/podtrzymanie działania)
Wszystkie nowe serwisy stawiamy na nginx/unicorn po tym jak taki zestaw sprawdził się najlepiej w wypadku najbardziej obciążonego z naszych serwisów.
nie zgodzę się, że apache/nginx to tylko kwestia upodobań i zastosowania - ten drugi bije na głowę apache jeśli chodzi o wydajność (chyba, że ostatnimi czasy dokonała się jakaś rewolucja, a ja o tym nic nie wiem).
Serwer ma być wyłącznie pod aplikacje railsowe, więc .htaccess jest właściwie zbędny…
zatem tu raczej skłaniam się ku nginxowi.
[quote]Co do samego serwera. Jeżeli zdecydujesz się na dedyka, to radzę Ci skonfigurować go używając chefa. Nie ma później sensu tracić czasu na konfigurację maszyny, gdy będziesz musiał zmienić serwer.
Jeżeli chodzi o dedyki. Uważaj na systemy preinstalowane. Na ovh na przykład są to jakieś stare wersje z podmienionymi repozytoriami, na których później często trzeba się namęczyć.[/quote]
cenna uwaga, choć mnie akurat nie dotyczy @Bragi - dzięki za ten opis, takich opisów właśnie potrzebowałem
Gdybyś miał jeszcze jakieś praktyczne porady dotyczące strojenia dedyka, będę b. wdzięczny
Blogga please. Mówisz o wydajności w znaczeniu serwowania statycznego contentu. W przypadku aplikacji railsowej będzie to akurat najmniej istotny “odcisk” na wydajności serwowanej aplikacji.
to fakt- najwięcej czasu zajmuje start ruby/aplikacji railsowej, ale skoro nie widać różnicy, to po co przepłacać?
[quote]Poproszę o benchmarki
Tylko najlepiej real life, a nie wykonanie pustej akcji kontrolera z render :text => “Hello world”.[/quote]
Fakt, że 90% benchmarków (czegokolwiek) publikowanych w sieci można spokojnie wysłać do /dev/null, bo nie pokazują one za wiele, ale nie spotkałem się z benchmarkiem pokazującym wyższość apacha.
Tylko mi się wydaje, czy jesteście raczej pro-apache? jesli tak to dlaczego? (bo chyba nie przez .htaccess)
Aha, i argument o tym, że apache może wystartować aplikacje w praktycznie dowolnym języku akurat do mnie nie przemawia, bo to będzie serwer ruby-only;)
Wiesz, to chyba też kwestia przyzwyczajenia. Ktoś postawił 100 serwerów Apache to Ci powie, że Apache. Ktoś inny zna nginix, to będzie polecał tenże.
To tak jak kiedys z wykładowczynią rozmawiałem. Sama się przyznała, że woli Microsoft Office, bo jest po prostu przyzwyczajona, a ludzie tych zmieniać nie lubią.
Nie jestem “pro-apache”, to zwykły pragmatyzm: apache jest wystarczająco wydajny, wystarczająco kompletny (ficzery, rozszerzenia, społeczność) i bardzo łatwy w konfiguracji i użyciu.
Natomiast po dwóch minutach czytania o konfigurowaniu nginx (włączając w to składnię plików konfiguracyjnych) porzygałem się niczym licealista na połowinkach.
plus nginx to ze zużycie ramu nie rośnie tak, przy kolejnych aplikacjach działających jak przy apachu. No ale kto w tych czasach sie ramem jakos mocno przejmuje?
Nie jestem pro-apache, wręcz przeciwnie, uwielbiam nginxa. Przed passengerem używałem go prawie od samego początku. Prawie, bo wcześniej był jeszcze lighttpd. Tylko tak jak napisał Tomash: czysty pragmatyzm. Jak będę potrzebował czegoś co ma apache (tak, .htaccess to też argument, jak z serwera korzystają też inni programiści z jakimiś aplikacjami php), to wezmę apacha, jak nginx będzie pasował w danej konfiguracji, to będzie nginx.
Witam po mojej dłuższej przerwie. Akurat dzisiaj jestem po testach passengera. Narazie nie mam za dużo benchmarków ale jedna rzecz rzuciła mi się w oczy - ilość zajętego ramu.
Jak pisałem kilka postów wyżej passenger to jakieś 50 ramu na instancje, nginx - ram jest stały nie rośnie wraz z instancjami. Jeśli chcecie wykresy, testy, jakieś itp to widziałem je na slajdach przedstawiających Node.js. Tak ps warto na Node.JS zerknąć, fajna sprawa.
Używam Ruby Enterprise od kilku miesięcy nie miałem z nim żadnego problemu, a zużycie pamięci faktycznie jest mniejsze, tak jak piszą twórcy passengera.