Konfiguracja serwera dedykowanego

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 :slight_smile:
@Bragi - dzięki za ten opis, takich opisów właśnie potrzebowałem :wink:
Gdybyś miał jeszcze jakieś praktyczne porady dotyczące strojenia dedyka, będę b. wdzięczny :wink:

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.

Poproszę o benchmarki :slight_smile:

Tylko najlepiej real life, a nie wykonanie pustej akcji kontrolera z render :text => “Hello world”.

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. :wink: 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.

Ok, a czy ktoś coś wie, używał może kiedyś, czegoś takiego jak Cherokee :> ?

http://www.cherokee-project.com/

404

Internet masz od ruskich i Ci nie działa.

Mi w domu jak i na uczelni śmiga. Sorry :wink:

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.

Konfiguracje testowe:
[] Test1: CentOS 5.4 x86_64, Intel Core2Duo E8400, 8GB RAM, guest w VirtualBox’ie: Ubuntu 8.04.3 LTS x86_64, 1GB RAM, ruby enterprise 1.8.7-2009.10, passenger 2.2.7
[
] Test2: FreeBSD 7.0 x86_64, Intel Core2Duo E8400, 8GB RAM, ruby 1.8.7 (2008-08-11 patchlevel 72)+GC PATCH, passenger 2.2.7

Ta sama aplikacja (CMS), “rozgrzana” od restartu przez

wget -k -m URL.

(co by się wszystko poładowało i po cachowało)

Wyniki:

Test1 (Ubuntu):

[code]---- Passenger processes ----
PID VMSize Private Name

7981 7.3 MB 1.1 MB /opt/ruby-enterprise-1.8.7-2009.10/lib/ruby/gems/1.8/gems/passenger-2.2.7/ext/apache2/ApplicationPoolServerExecutable 0 /opt/ruby-enterprise-1.8.7-2009.10/lib/ruby/gems/1.8/gems/passenger-2.2.7/bin/passenger-spawn-server /opt/ruby-enterprise-1.8.7-2009.10/bin/ruby /tmp/passenger.7967
7982 18.4 MB 5.8 MB Passenger spawn server
9293 36.2 MB 16.9 MB Passenger ApplicationSpawner: /var/www
9295 52.7 MB 25.7 MB Rails: /var/www[/code]
Test2 (FreeBSD):

[code]----- Passenger processes ------
PID VMSize Resident Name

9192 11.7 MB 2.7 MB /usr/local/lib/ruby/gems/1.8/gems/passenger-2.2.7/ext/apache2/ApplicationPoolServerExecutable 0 /usr/local/lib/ruby/gems/1.8/gems/passenger-2.2.7/bin/passenger-spawn-server /usr/local/bin/ruby18 /tmp/passeng
9291 35.2 MB 18.4 MB ruby18: Passenger spawn server (ruby18)
50332 87.3 MB 54.7 MB ruby18: Passenger ApplicationSpawner: /var/www (ruby18)
50631 114.2 MB 62.4 MB ruby18: Rails: /var/www (ruby18)[/code]
Jak widać ta sama aplikacja na Linuxie + Ruby Enterprise ma znacznie mniejsze wymagania niż ta na FreeBSD.

Jeżeli Ruby Enterprise jest w 100% kompatybilny (a tak mówią jego twórcy) z “normalnym” ruby to warto się zastanowić czy go nie użyć.

Pozdrawiam
Pawel

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.

Do tego topicu polecam slajd 9-10

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.