Witam mam do wyboru na hostingu megiteam.pl możliwośc uruchamiania aplikacji Railsowych w trzech trybach
Thin
FastCGI
Mongrel
Podpowiedzcie co do czego się najlepiej nadaje, co do mniejszych rzeczy co do większych…
I jeszcze takie pytanko, czy Sqlite3 nadaje sie tylko do developmentu, czy cos małego można na tym zostawić w trybie produkcyjnym (wygodne to jest).
Pozdrawiam
nie radzę używać sqlite3 - oprócz tego, że czasem robi różne dziwne rzeczy (mi kiedyś psuł testy), to stosuje “wesołą” metodę blokowania bazy danych - blokuje cały plik z poziomu systemu. czyli gdy ktoś robi zapis nikt inny nie odczyta.
co do hostowania - na pewno nie fastcgi. ktoś pisał w której książce, że to jak rakieta, która może wybuchnąć w każdej chwili 
z thinem doświadczeń nie mam, a mongrel działa dobrze 
O FastCGI zapomnij, Thin i Ebb mają się nienajlepiej, zdecydowanie Mongrel.
Kiedy potrzebowaliśmy użyć Mongrela, to okazało się, że jest niekompatybilny z Ruby 1.9, być może się to już zmieniło. Od jakiegoś czasu używamy z powodzeniem Thina, działa bez zarzutów. Co do Ebb to się zgodzę, ciężko znaleźć cokolwiek aktualnego na jego temat (od jakiegoś czasu nikt się nim nie zajmuje). Odnośnie SQLite - baza ta nie umożliwia wielodostępu, w związku z tym nie nadaje się do środowisk produkcyjnych (w Wikipedii ktoś napisał, że jeśli chodzi o wydajność dla jednego połączenia, to wypada całkiem nieźle w porównaniu do Postgres czy MySQL; jeśli nie potrzebujemy żadnych fajerwerków typu Sphinx, to SQLite nadaje się wyśmienicie do środowisk rozwojowych i testowych).
Mongrela da się zmusić do pracy z 1.9: http://isitruby19.com/mongrel – gorzej było z gemem MySQL (zwłaszcza że Passenger wspiera Ruby 1.9.1 już od bardzo dawna), chociaż podobno już działa (http://isitruby19.com/mysql)
Niemniej wciąż obawiam się, że poważne railsowanie z ruby 1.9 na pokładzie to najwcześniej na gwiazdkę albo po sylwestrze będzie można zacząć.
A tak swoją drogą to stawiam ojro przeciw orzechom, że koledze Pskiemu chodziło jednak o railsy z użyciem 1.8.x
PS. Mea pulpa że nie obtestowałem Thina, ale w innym wątku – w którym właśnie pytałem o railsy 2.2 z ruby 1.9 – Hosiawak mnie zniechęcił.
Tzn. Thin teraz pod 1.9 nie ma gorszej wydajności niż webrick ? Czy ktoś mógłby to potwierdzić ?
Pamiętam jak testowałem pół roku temu to było źle, może teraz się zmieniło.
Coś się zmieniło od tego czasu ? też mam dylemat co lepsze na produkcji, Thin czy Mongrel ? Ruby 1.8 i Rails 2.3.5 narazie.
Robiłem ostatnio benchmarki i okazało się, że zestaw nginx+thin (Ruby Enterprise Edition 1.8.7 + Rails 2.3.5) jest o 7% szybszy niż Apache2 + passenger. W parę dni później przełączyliśmy kilka serwerów produkcyjnych na taki zestaw.
Dodatkowy bonus to fakt, że nginx + thin dają sobie radę z problemem C10k. Apache dla odmiany nas zawiódł - musieliśmy wyłączyć keep-alive, żeby dać sobie radę z natłokiem klientów.
Jesteś bardzo złym człowiekiem, Bragi
Trochę dziwny test. To co porównywałeś, nginx vs apache czy thin vs passenger? Jeśli chodzi o ten 1 zestaw to nginx jest szybszy i zużywa o wiele mniej pamięci. Z kolei IMHO porównywanie thina i passengera nie ma za bardzo sensu. Im dłużej żądanie siedzi w railsach tym bardziej zatraca się jakakolwiek różnica w wydajności tych serwerów aplikacyjnych. Ja osobiście stawiam na passangera bo prócz prostoty dostaję taki bonus że nie muszę się martwić o memleaki (passenger sam co jakiś czas restartuje procesy).
Mam podobne doświadczenie. Nginx rządzi i konfiguracja jest bardzo prosta i przyjemna. W piku 250r/s, ponad 1000 aktywnych połączeń i tylko 22MB ram.
Zaskoczenie tygodnia: liczyłem że “młodzież” da się strollować tymi siedmioma procentami Bragiego (i będzie je potem powtarzać, a nawet podając autorytet Bragiego jako argument), a tu proszę – taki wyjadacz jak Radarek dał się podejść 
I jeszcze łyknąłeś fragment o C10k
C10k dla serwera aplikacji Rails
Trzeba jakoś oznaczać po dniu-dwóch takie wypowiedzi jakąś zieloną ramką z podpisem “autor sobie robi jaja”, bo skoro Radarek to kupił, to strach pomyśleć ilu mniej biegłych rubiowców wzięła wypowiedź Bragiego z pełną powagą.
Idę w zakład, że pisał serio. Gdyby nie to ostatnie zdanie to jeszcze może uznałbym to za żart, natomiast ten dopisek o keep-alive jest jak najbardziej prawdziwy i faktycznie pierwsze co się robi przy apache przy wielu połączeniach na raz to obniża wartość keep-alive. Oczywiście, że C10k bezpośrednio nie tyczy się railsów, ale frontendowych serwerów http, np. nginx a o tym serwerze Bragi pisał. Pracuję przy takiej aplikacji która po części ma taki problem (większość ruchu jest serwowana przez statycznie skeszowane pliki, ale te pliki są generowane przez railsy). Gdyby Bragi napisał, że C10k tyczy się mongrela/thina lub innego serwera aplikacyjnego to faktycznie byłoby to śmieszne. Skoro napisał o tym w kontekście nginxa to nie widzę tu żadnego podpuszczania.
Kurde, to teraz ja jestem skołowany
Admina proszę o zaznaczenie postu Tomasha zieloną ramką :P.
Nie ma jak pisać w skrócie 
Mieliśmy poważny i nie dający się ani zdiagnozować ani tym bardziej rozwiązać problem z Bundlerem w zestawie Apache+Passenger.
Ta sama aplikacja pod Thinem działała bez zarzutu. Dla pewności przeprowadziłem benchmarki na serwerze produkcyjnym. Wyniki są dostępne na moim blogu.
Wywalenie Apache (a zwłaszcza Passengera) pozwoliło na użycie Bundlera i ułatwiło zarządzania gemami. Jednocześnie nginx jest łatwiejszy w konfiguracji i nie wykazuje problemów z dużą liczbą połączeń (w przeciwieństwie do Apache). 7% przyrost prędkości w nowym ustawieniu traktuję bardziej jako bonus i ciekawostkę - ale warto o tym wiedzieć.
Jezusicku, to weź nie pisz w formie sugerującej że 7% różnicy wydajności było powodem tak poważnej migracji.
Oraz: nginx rozumiem, ale czemu Thin a nie Unicorn?
Ja od siebie dodam, że nie mamy problemów ani z apache+passenger+bundler ani nginx+passenger+bundler (tak dla pewności żeby ktoś się nie zasugerował, że bundler nie działa z passengerem na apachu).
+1
Byłeś na spiczu Yehudy na Euruko? “It’s a Bundler issue!!!”
Między innymi: Improved Bundler support.
Bo Thin daje deterministyczne działanie w chmurze Unicorn jest OK jeśli masz jeden node. Przy większej ilości nodes musisz postawić HAProxy a Unicorn ‘oszukuje’ HAProxy kolejkując zadania wewnętrznie. Thin dla odmiany dzielnie zajmuje się jednym requestem na raz dzięki czemu HAProxy wie, że musi sięgnąć do innego node z nowym requestem.