Z racji wymagań biznesowo-technicznych potrzebujemy, żeby nasza aplikacja odpowiadała na request niezwłocznie, czyli bez overheadu związanego ze startem aplikacji (mamy narzucony timeout rzędu 2-4 sekund, aplikacja spokojnie się mieści w półtora, pod warunkiem że nie ma dodanych piętnastu na start).
Passenger po ustawieniu MaxIdleTime 0 teoretycznie nie ubija aplikacji, ale po każdym deployu albo restarcie/reloadzie apacza aplikacje Railsowe leżą i się podnoszą dopiero przy pierwszym żądaniu. Obchodzenie poprzez “curl http://aplikacja” przy każdym deployu jest brzydkie i nie załatwia nam spraw typu restarty serwera (czy to maszyny, czy apacza) – a głupio oczekiwać od naszego admina, żeby takich rzeczy pilnował.
Dość oczywistym jest rozwiązanie oldschoolowe, czyli apacz jako zaledwie proxy do klastra mongreli czy thinów.
Wadą tego rozwiązania jest stała i niezmienna liczba dostępnych serwerów aplikacji (może się okazać że potrzebujemy kilku instancji więcej albo kilku mniej, żeby np. zwolnić ram dla memcached). Poza tym upierdliwość zarządzania takim klastrem – jak workery zdechną, trzeba wymyślać jakieś dodatkowe rozwiązania do autostartu i zarządzania nimi.
Idealny byłby scenariusz: w momencie restartu/deploymentu wstaje X (np. 5) gotowych instancji serwerów aplikacji, czekających na zgłoszenie. Y instancji (np. dwie) ma być zawsze wolnych (Y<X), po przekroczeniu (w dół) tej liczby startują kolejne instancje i czekają na żądania (ew. zdychają po kilkudziesięciu minutach braku żądań, żeby liczba idle serwerów wrociła do Y). Oczywiście ilość instancji nie przekracza liczby Z, narzuconej przez ilość dostępnych zasobów (np. 20).
Czyli coś jak apaczowe (niestety nie passengerowe) StartServers, MinSpareThreads, MaxSpareThreads itd.
W Passengerze przydałaby się w takim razie opcja AutoWarmup (aplikacja jest ładowana zaraz po starcie Apache’a oraz po restarcie) chociaż nie wiem czy ludzie z Phusion to zaakceptują. Może warto zapytać na grupie http://groups.google.com/group/phusion-passenger ?
Moze glasfish z jruby on rails, nie wiem jaki jest status tego roziwazania i jak ono sie sprawdza. Ale z tego co kojarze mozesz definiowac max i min ilosc instancji. Nie wiem jak szybko cos takiego wstaje po deployu.
W sumie to Unicorn powstał do tego, ludzie z GitHub’a niedawno pisali jak to działa u nich Tyle, że tutaj Tomash nie chce mieć stałej liczby workerów (nie chce, nie może, ograniczony jest pamięcią).
Tzn. są dwie maszyny aplikacyjne, na każdej 4GB ramu.
Właśnie mnie Drogomir poprawił, że memcached raczej będzie na maszynach bazodanowych (mają po 16GB), czyli cały ram na aplikacyjnych jest na aplikację.
Czyli zasadniczo można pojechać oldschoolowym klastrem mogreli/thin/unicorn – który z tych serwerków będzie najlepszy?
Także w sensie zarządzania workerami w klastrze (automatyczne podnoszenie po padzie itd.)?
Według tego co piszą na stronie unicorna workery można ubić/wystartować praktycznie natychmiastowo, a narzut jest spowodowany tylko startem mastera. Dlatego ja też bym poszedł w tą stronę.
Myśle, że może się przydać.
TTIN - increment the number of worker processes by one
TTOU - decrement the number of worker processes by one http://unicorn.bogomips.org/SIGNALS.html
Unicorn jest 666/10
Filozofia, konfiguracja i działanie mnie absolutnie kupiły. Od dziś chodzi na tym nasz “flagowy” projekt, który od poniedziałku dostanie mocno po garach jeśli chodzi o ilość odwiedzin/użytkowników.
Apacz do rezerwatu!
Kto chce się dowiedzieć co i jak na najbliższym WRUGu w ten wtorek?
) i w poniedziałek-wtorek wyrzucimy apacza na śmietnik.