🚀 go-pugleaf

Jan Słupicki wrote:

> pl.comp.lang.ruby
> Czy Webrick uruchamia oddzielne wątki dla obsługi każdego request-u ?

AFAIK nie.
Użyj mongrela. Jak go zainstalujesz to stanie się domyślnym serwerem przy
developerce.

-- 
.:: Piter // phlawski$gmail,com // gg: 4534287 ::.
Chuck Norris zaskarżył NBC o to, że nazwa Prawo i Porządek są zastrzeżonymi
nazwami jego lewej i prawej nogi.

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

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

On Mon, 03 Sep 2007 10:33:03 +0100, Piotr 'piter' Hlawski  
<phlawski@cut_this_crap.gmail.com> wrote:

> Użyj mongrela. Jak go zainstalujesz to stanie się domyślnym serwerem przy
> developerce.

Użytkowników FreeBSD może skusić plugin webrick-high-performance. Powinien  
być szybszy od Mongrela, bo zapuszcza kilka forków (Mongrel działa  
bardziej jak jeden proces). Taki dopalony Webrick powinien dać duże  
przyśpieszenie i od biedy zastąpić nawet Apache'a.

http://dev.robotcoop.com/Libraries/webrick-high-performance/files/README.html

-- 
Jarosław Zabiełło
http://blog.zabiello.com

Jaroslaw Zabiello pisze:
> Użytkowników FreeBSD może skusić plugin webrick-high-performance. 
> Powinien być szybszy od Mongrela, bo zapuszcza kilka forków (Mongrel 
> działa bardziej jak jeden proces). Taki dopalony Webrick powinien dać 
> duże przyśpieszenie i od biedy zastąpić nawet Apache'a.
> 
> http://dev.robotcoop.com/Libraries/webrick-high-performance/files/README.html 
> 

Ostatnio zainstalowałem plugin dev_mode_performance_fixes, 
http://www.robbyonrails.com/articles/2007/08/28/rails-development-performance-tip-dev_mode_performance_fixes

Nie wiem jak pod linuksem ale pod windowsem widać ogromną różnicę. 
Aczkolwiek nie jest to jeszcze doskonały plugin, czasem zdarza się, że 
trzeba zrestartować serwer, żeby widoczne były zmiany w kodzie.

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

A jak inaczej uzyskać właściwość "zmiennej globalnej" która byłaby
widoczna tak w kontrolerze jak i w modelu (w serwerze jednowątkowym) ?
Hmm - może klasa singletonowa ?

--
Jan Słupicki

> do obiektu sesji w modelu :http://www.zorched.net/2007/05/29/making-session-data-available-to-mo...
> ale rozwiązanie to jest oparte właśnie na założeniu że każdy request
> jest
> obsługiwany przez osobny wątek.

Po głębszym zastanowieniu to nie ma problemu. Jak serwer jest
jednowątkowy
to przecież nie może się zdażyć że jeden request zakłóci działanie
innego
poprzez nadpisanie zmiennej w Thread.current[]

--
Jan Słupicki