Hej,
w jakich sytuacjach lepiej używać pumy a w jakich unicorna?
Puma używa wątków, więc na MRI wiele nie zdziała -> JRuby, Rubinius
Unicorn używa forków -> MRI
Zresztą, sami twórcy Pumy zalecają używania tego serwera jedynie w przypadku Ruby’ego, który obsługuje w normalny sposób wątki. Tutaj jest ciekawy post na temat forków i wątków: http://blog.gregweber.info/posts/2011-06-16-high-performance-rb-part3
[quote=konole]Puma używa wątków, więc na MRI wiele nie zdziała -> JRuby, Rubinius
Unicorn używa forków -> MRI[/quote]
Niezupełnie tak jest. Ten post, który podałeś, dużo wyjaśnia. Nawet w przypadku MRI wątki mogą pomóc.
W MRI jest tak, że istnieje ten niesławny Global VM Lock, który nie pozwala, aby dany kod jednocześnie był wykonywany przez więcej niż 1 wątek. Natomiast ten lock jest zwalniany (automatycznie przy non-blocking IO i może być ręcznie zwolniony w rozszerzeniach napisanych w C).
Tak więc to, czy wątki w MRI pomogą w Twojej aplikacji czy nie, zależy od tego ile czasu aplikacja spędza na IO. Na EuRuKo miałem okazję opowiadać o aplikacji, w której 80% czasu obsługi requestu poświęcone jest na czekanie na odpowiedź zewnętrznych API. Dzięki temu, że uruchamiamy tę aplikację w trybie wielowątkowym (próbowaliśmy z Pumą, przenieśliśmy się na Phusion Passenger), dużo lepiej wykorzystujemy zasoby.
W przypadku Rubiniusa 2.x czy JRuby sprawa jest prosta, bo wystarczy 1 proces na cały serwer, natomiast w przypadku MRI trzeba odpalić przynajmniej po 1 procesie na każdy rdzeń procesora. Puma wspiera taką opcję, żeby dopasować sobie jenocześnie i liczbę procesów i liczbę
wątków na proces.
Natomiast tam, gdzie ograniczeniem nie jest IO a procesor, wątki w MRI nie pomogą, więc wtedy warto zostać przy Unicornie.
A moglibyście podać przykłady kodu z blocking and non-blocking IO?