[quote]Matt Freels says
Unicorn can restart your app without any lost requests or stalls.
Passenger drops your app and its workers, and then lets the next request bring the new version up.
I would say the biggest difference is that where Passenger is opinionated and fairly all-or-nothing, Unicorn gives you more transparency and control over its configuration (while still nicely managing workers).[/quote]
Bawił się ktoś unicornem?
Czy to zwróci true? -> (unicorn > passenger)
Wszystko zależy od tego jakie masz potrzeby, passenger też ma swoje zalety. To co mogę powiedzieć na pewno, to fakt, że passeger lite działa kiepsko (albo coś robię źle), bo podczas deployów przy proxy w apachu serwis leży aż nie wystartuje nowa instancja.
Trzeba przyjąć założenie: albo mamy monitoring, albo nie mamy go wcale. Rozumiem, że masz tu na myśli to, że passenger domyślnie startuje aplikacje przy pierwszy requeście. Tak jak passenger ma swojego zarządcę do workerów, dzięki czemu “apache podnosi” procesy passengera tak samo unicorn ma swój proces master, który robi forki z workerami, którymi zarządza. I jedno i drugie może się wysypać.
Swoją drogą bardziej od tego, że mi wyleci unicorn boję się, że ktoś co bardziej pomysłowy wyda update rubygems, rvm lub rails i będę mięc problemy w stylu:
;)))
Zauważ, że aby odpalić passengera (mówimy o konfiguracji jako moduł do nginx lub apache) musimy zbudować/skompilować moduł do serwera www
W przypadku unicorna odpalamy tylko daemona i dodajemy konfigurację, aby proksować na socket unicorna.
No dobra, tu już się czepiam trochę … co nie zmienia faktu, że uważam, że konfiguracja jest równie prosta
Jako ważną kwestię można poruszyć bezpieczeństwo. Master proceses działa jako root, dopiero workery są robione jako setuid(), więc teoretycznie istnieje prawdopodobieństwo wyexplojtowania tego, a jak wiadomo taki apache jest tak bezpieczny jak jego moduły, z których korzysta
W przypadku unicorna tego problemu nie mamy.
Podaj przykład
Chociaż swoją drogą ruby i współbieżność… 3;)
Dla przykładu do teraz w 1.8.7 nie poprawili błędu z serializowaniem Marshalem w wątkach:
[code]require ‘thread’
require ‘socket’
Thread.abort_on_exception = true
threads = []
rcv,snd = IO.pipe
threads << Thread.new do
obj = (‘a’…‘z’).inject({}){|h,s|h[s.intern]=s*1024;h}
data = Marshal.dump(obj)
snd.write(data[0,data.size/2])
sleep(1)
snd.write(data[(data.size/2)…-1])
end
threads << Thread.new do
lock = Mutex.new
lock.synchronize do
Marshal.load(rcv)
end
end
threads << Thread.new do
100.times do
GC.start
end
end
threads.map{|t| t.join}[/code]
… i po odpaleniu mamy
Aborted[/code]
No dobra, ale aby nie offtopować. Też uważam, że unicorn daje radę, choć w wielu przypadkach nie robi różnicy nginx + passenger, czy nginx + unicorn.
Chodziło mi o to że Passenger jest ograniczony do jednej wersji Ruby.
Czy takie same ograniczenia ma Unicorn.
Anyway… good to know. ;)[/quote]
Passenger jest pluginem do apacha, a na unicorna tylko lecą requesty poprzez proxy (z apacha lub nginxa), stąd ta różnica.
Czy na developmencie unicorn też tak zamula jak passenger?
Chodzi mi o to że jeśli aplikacja przez dłuższy czas nie łapała requesta, to po prostu jest spawnowana od zera (tak jest w passengerze).
Zajmuje to dość dużo czasu(IMHO, nie chce mi się czekać 5-10s na odpowiedź aplikacji).
Pytam z ciekawości, nie mam zamiaru zaorać cały VPS żeby zyskać parę sekund.
[quote=Matthias]Czy na developmencie unicorn też tak zamula jak passenger?
Chodzi mi o to że jeśli aplikacja przez dłuższy czas nie łapała requesta, to po prostu jest spawnowana od zera (tak jest w passengerze).
Zajmuje to dość dużo czasu(IMHO, nie chce mi się czekać 5-10s na odpowiedź aplikacji).
Pytam z ciekawości, nie mam zamiaru zaorać cały VPS żeby zyskać parę sekund. ;)[/quote]
Ustaw sobie “PassengerMinInstances 1” i po kłopocie.
… co nie zmienia faktu, że uważam, że konfiguracja jest równie prosta
)