🚀 go-pugleaf

Wielowatkowosc mongrela osiaga sie poprzez roznorakie load balancery dla 
serverow www, brak natywnej wielowatkowosci w zasadzie nie jest w niczym 
przeszkoda mozna smialo stawiac aplikacje na 3-4 procesach mongrela, 
spiete balancerem apacha albo lighttpd. Problemy zacyznaja byc w 
momencie gdy mamy te 3-4 dzialajace procesy mongrela i zazyczylibysmy 
sobie dzielenie pomiedzy nimi tej samej konfiguracji aplikacji. Kazdy 
proces jest w zasadzie autonomiczny wiec trzeba o tym pamietac w pewnych 
okreslonych przypadkach (np stale w klasach przy wlaczonym 
cachowaniu(domyslne w production cachowanie klas) beda zapamietywane w 
obrebie procesu mongrela).

Dnia 9/3/07 10:53 PM, Łukasz Piestrzeniewicz napisał(a):
> On Mon, 03 Sep 2007 09:21:29 +0000, Jan Słupicki wrote:
> 
>> Czy Webrick uruchamia oddzielne wątki dla obsługi każdego request-u ?
>> Wyczytałem że Mongrel tak właśnie robi. Znalazłem poradę jak dostawać
>> się do obiektu sesji w modelu :
>> http://www.zorched.net/2007/05/29/making-session-data-available-to-models-in-ruby-on-rails/
>> ale rozwiązanie to jest oparte właśnie na założeniu że każdy request
>> jest obsługiwany przez osobny wątek.
> 
> To rozwiązanie akurat zapewnia spójny dostęp do obiektu sesji *pomimo*
> wielu równolegle działających wątków. W wypadku serwera jednowątkowego
> (w szczególności webrick) nie ma potrzeby uciekać się do Thread.current.
> 
> Inna sprawa, że AFAIK Rails póki co działają prawidłowo tylko w jednym
> wątku per proces. Nawet mongrel obsługuje na raz tylko jeden request w
> Rails. Może co prawda jednocześnie serwować kilka plików statycznych w
> innych wątkach ale w obrębie procesu nadal działa tylko jeden wątek Rails.
> 
> Podane rozwiązanie jest jednak future-proof i warto z niego skorzystać.
> 
> Pozdrawiam,
> Łukasz