Napisałem posta o dyskusji zapoczątkowanej rantem Zeda i postem na blogu dreamhosta. Jak to wszystko widzicie? Jest jakaś szansa na poprawę? Czy Railsy są za wielkie, żeby cokolwiek dało się zrobić?
Nie pracuje na dzielonych hostingach, who cares ? 
Dzis ceny dedykow/root vps’ow sa tak smieszne ze serio, who cares ? Jest mongrel, jest evented mongrel, capistrano, fastcgi, tworzony jest rack, jako frontend jest apache, lighttpd, ngix. Zreszta nie wiem co by jeszcze mozna poprawic, nigdy nie bedzie tak jak w przypadku php, mozna raczej to skierowac w strone tomcat’a z wbudowanym vm w jeden z wielu wysokowydajnych serverow http
Poprawić można by chociaż to, żebym mógł pod linuxem zrobić coś w stylu:
apt-get install nginx ruby postgresqli po prostu wrzucić skrypty rubiego do jakiegoś katalogu i odpalać tak jak php. Wiem, że jest Ramaze, Camping i inne tego typy lightowe frameworki, ale naprawdę czasami chcę po prostu zrobić coś naprawdę bardzo bardzo bardzo prostego i nie mam ochoty odpalać skryptu, który ma 10 linijek rubiego na oddzielnym porcie, ani robić sobie specjalnie aplikacji, żeby takie skrypciki uruchomić.
Od długiego czasu pracuję tylko na dedykach, jeżeli nie miałbym dostępu do dedyka, to pewnie wykupiłbym VPSa. Tylko tak jak napisał koleś z dreamhostu, większość początkujących nie ma takiej możliwości. Nikt nie wykupi VPSa, żeby postawić swoją małą aplikacyjkę i pokazać znajomym.
A jak jeszcze o tym pomyślałem… Nie chciałbyś, żeby aplikacje Railsowe nie zjadały tyle ramu? Każdy mongrel zjada po przynajmniej 30-40 megabajtów, z reguły dużo więcej. Już na dzieńdobry pusta aplikacja zajmuje około 20 mega. Dla porównania uruchomienie pustej aplikacji merba to 12 mega.
Nie wiem czy się da coś w tym momencie zrobić i czy jest szansa, że ktoś zacznie, ale fajnie by było gdyby ktoś z tym wreszcie coś zrobił. Ogólnie wiadomo, że DHH nigdy nie zajmował się optymalizacją. Może czas zacząć?
A tak na marginesie, od jakiegoś czasu poważnie zastanawiam się nad przejściem na Merba, szczególnie, że wydajnośc to nie jedyny plus tego frameworka.
Jesli chodzi o ruby odpalane jak php to jest do tego chyba mod_ruby
Jesli chodzi o to ze mongrele jedza duzo ramu to wyjsciem jest evented mongrel, natomaist ja osobiscie polecam zwrocenie uwagi na rubinius’a jesli komus zalezy na kompatybilnosci z MRI (ruby oraz rozszerzenia z ruby c) oraz na tym aby aplikacje dzialaly szybciej oraz zjadaly znacznie znacznie mniej ramu to rubinius jest ta wlasnie alternatywa.
Przez optymalizacje rails cudu nie bedzie, problemem na dzien dzisiejszy jest chyba implementacja rubego MRI jest kiepske, yarv to zupelnie inna para kaloszy, jruby wcale nie jest jeszcze najszybszy jesl chodzi np o rails, natomiast rubinius nie jest skonczony Ale wszystko zmierza w dobrym kierunku ja licze ze za 10 miesiecy bede mogl wszystkie moje aplikacje rails 1.2.x przeniesc spokojnie na rubiniusa da to kopa i dla wydajnosci i dla memory footprint.
Prawdą jest, że na hostingu współdzielonym uruchomienie aplikacji w Railsach nie jest zadaniem prosty. Jednak wydaje mi się, że to właśnie w gestii firmy hostingowej, która chce oferować wsparcie dla RoR z prawidzwego zdarzenia a nie tylko na zasadzie “jeżeli uruchomisz sobie mongrela to my ci go nie ubijemy” leży ułatwienie użytkownikom uruchamiania aplikacji. Specyfika hostingu RoR jest taka a nie inna. Firmy hostingowe przyzwyczaiły się do PHP i traktują je jak wyznacznik pomijając fakt, że od strony środowiska hostingowego Railsom bliżej do Javy niż PHP. Skoro wiadomo, że manager fastcgi z Apache procesy fastcgi, które nic nie robią, co jakiś czas ubija (oszczędność), a przy starcie aplikacja w Railsach kompilowana jest w całości wraz ze wszystkimi bibliotekami co może trochę potrwać, to dlaczego odpowiedź od społeczności Railsowej, by nie używać Apache z fastcgi Dreamhost uważa za głupią? Bo z PHP to działa? W przypadku PHP jako proces fastcgi uruchamiany jest jedynie lekki interpreter tego języka - użytkownik opóźnienia w wyświetleniu strony związanego z uruchomieniem procesu PHP nie zauważy. Fakt, że nie ma jeszcze dobrego wsparcia wśród dostępnego oprogramowania dla hostingów alternatywnych: przydałby się manager procesów z prawdziwego zdarzenia, panele administracyjne uwzględniające specyfikę serwerów aplikacji, ale skoro nam (http://megiteam.pl) udało się udostępnić klientom środowisko współdzielone w którym użytkownik uruchamia aplikację w Railsach tak łatwo jak w PHP to taka firma jak Dreamhost tym bardziej nie powinna mieć z tym żadnego problemu
Pozdrawiam
Tylko większość użyszkodników (w tym ja na przykład) w ogóle nie używa apacha. Nie chcę instalować go i stawiać na oddzielnym porcie i robić proxy, tylko dla mod_ruby Właśnie o tą prostotę mi chodzi… php mam na nginxie przez fastCGI, chciałbym tak samo łatwo dołączyć rubiego.
A są jakieś testy porównujące porównanie pożeranie pamięci i procka przez rubiniusa i MRI? Nie słyszałem o tym jakie są różnice Na rubiniusa, na którym będzie można odpalić Railsy czekam z niecierpliwością. Ezra staje się przy okazji moim prywatnym bohaterem 
Nie dość, że napisał merba, to jeszcze wynajął 5 programistów do rozwijania rubiniusa
[quote=megi]Prawdą jest, że na hostingu współdzielonym uruchomienie aplikacji w Railsach nie jest zadaniem prosty. Jednak wydaje mi się, że to właśnie w gestii firmy hostingowej, która chce oferować wsparcie dla RoR z prawidzwego zdarzenia a nie tylko na zasadzie “jeżeli uruchomisz sobie mongrela to my ci go nie ubijemy” leży ułatwienie użytkownikom uruchamiania aplikacji. Specyfika hostingu RoR jest taka a nie inna. Firmy hostingowe przyzwyczaiły się do PHP i traktują je jak wyznacznik pomijając fakt, że od strony środowiska hostingowego Railsom bliżej do Javy niż PHP. Skoro wiadomo, że manager fastcgi z Apache procesy fastcgi, które nic nie robią, co jakiś czas ubija (oszczędność), a przy starcie aplikacja w Railsach kompilowana jest w całości wraz ze wszystkimi bibliotekami co może trochę potrwać, to dlaczego odpowiedź od społeczności Railsowej, by nie używać Apache z fastcgi Dreamhost uważa za głupią? Bo z PHP to działa? W przypadku PHP jako proces fastcgi uruchamiany jest jedynie lekki interpreter tego języka - użytkownik opóźnienia w wyświetleniu strony związanego z uruchomieniem procesu PHP nie zauważy. Fakt, że nie ma jeszcze dobrego wsparcia wśród dostępnego oprogramowania dla hostingów alternatywnych: przydałby się manager procesów z prawdziwego zdarzenia, panele administracyjne uwzględniające specyfikę serwerów aplikacji, ale skoro nam (http://megiteam.pl) udało się udostępnić klientom środowisko współdzielone w którym użytkownik uruchamia aplikację w Railsach tak łatwo jak w PHP to taka firma jak Dreamhost tym bardziej nie powinna mieć z tym żadnego problemu
Pozdrawiam[/quote]
Szczerze mówiąc nie wiem jak wygląda działanie firm hostingowych od środka, więc nie będę się wypowiadał Mógłbyś napisać jak wy sobie z tym radzicie? SCGI? FCGI? mongrel?
Co do reszty wypowiedzi. Wcale nie twierdzę, że php powinien być wzorcem. Po prostu nie lubię stwierdzenia: “komu to potrzebne? bez sensu w ogóle o tym myśleć”. Jakby ludzie nie mysleli o rozwoju, to nie byłoby teraz pewnie mongrela
Wiem, że to brzydko się chwalić, ale pękam z dumy i nie mogę się powstrzymać: “mój” programista, który pisał dla Ezry moduł do Nginxa dostał propozycję napisania mod_rubinius do Apache i Nginxa
Szczerze mówiąc nie wiem jak wygląda działanie firm hostingowych od środka, więc nie będę się wypowiadał Mógłbyś napisać jak wy sobie z tym radzicie? SCGI? FCGI? mongrel?[/quote]
Mogłabym
Ponieważ my od początku byliśmy nastawieni na taki alternatywny hosting dostosowany do specyfiki RoR, Django itp. i wszystko projektowaliśmy od zera to na pewno było nam łatwiej niż firmom, dla których hosting Rails jest dodatkiem do już działającego hostingu PHP. Ogólnie wygląda to tak, że najpierw przez ssh na serwerze trzeba stworzyć szkielet aplikacji (chyba, że ktoś przenosi działającą aplikację z innego serwera to po prostu ją wgrywa na serwer), później w panelu administracyjnym dodaje się nową aplikację podając katalog, wybiera się liczbę procesów, które mają ją obsługiwać, dodaje domenę i to tyle po stronie użytkownika (minuta roboty) Panel zapisuje wyklikane informacje do bazy danych, zostaje powiadomiony agent www odpowiedzialny za skonfigurowanie nginxa do obsługi tej aplikacji (jako proxy lub fastcgi - zależy co użytkownik wybrał z listy wpieranych frameworków) oraz uruchomienie procesów użytkownika. Skonfigurowanie nginxa polega na pobraniu z bazy szablonu konfiguracji przygotowanej pod konkretny framework, wypełnieniu takich danych jak port i ip mongrela, katalog domowy aplikacji, domena itp. i zapisanie do pliku. Każdy uruchomiony przez tego agenta proces jest monitorowany i jeżeli zostanie np. ubity przez użytkownika, bo wprowadził zmiany w kodzie to agent natychmiast go uruchamia. A jeżeli z jakiegos powodu aplikacja się nie uruchamia (np. z powodu błędnie skonfigurowanego połączenia do bazy danych) to my dostajemy o tym maila Wszystko chodzi jak w zegarku
Niestety mod_ruby pozostawia wiele do życzenia. Współdzieli np. kod między odpalanymi skryptami (np. klasa zdefiniowana w jednym skrypcie, będzie widoczna w drugim, więc nie trudno o konflikt). Tak przynajmniej pisali ludzi w komentarzach na http://rubyinside.com. Trzeba pamiętać, że php został stworzony tylko dla weba, stąd cała obsługa http jest wbudowana w sam interpreter. W Rubym musiałbyś dołączyć przynajmniej cgi.rb co dodaje kolejne opóźnienie. Załadowanie w ten sposób railsów jest niepraktyczne, bo przy każdym żądaniu ładowana byłaby cała aplikacja - poprawcie mnie jeśli się mylę.
To nawet nie tyle mongrel zjada dużo ramu co same railsy. Na myślenie o rubiniusie w kontekście produkcyjnym jest jeszcze zdecydowanie za wcześnie.
Nazywanie MRI kiepskim to zbyt poważne słowa. Może się czepiam, ale jeśli my, programiści Rubiego, mówimy że MRI jest kiepskie (jak rozumiem “wolne”?) jest pomyłką. A potem dziwić się, że wszyscy mówią, że Ruby jest wolna. I tak pewnie będzie nawet jak 1.9 będzie już używana w praktyce.
Yarv, czyli ruby 1.9, to inna para kaloszy? W jakim sensie? 1.9.0 (aktualna wersja) oczywiście jest oznaczona jako dev, aktualnie trwają testy przez społeczność (zachęcam każdego do tego), kolejne wersje (1.9.x, x >= 1) mają docelowo być stabilne i przeznaczone do użytku produkcyjnego. Większość autorów gemów, bibliotek, frameworków prowadzi już prace nad kompatybilnością z 1.9 (zmian jest trochę, ale nie powinno być z tym większych problemów).
JRuby jest dosyć szybki, aczkolwiek rzeczywiście mają gdzieś wąskie gardło w przypadku rails (i ciągle nie mogą znaleźć :D). Mało tego. Zrobiłem sobie testy pewnego własnego programu (drzewo czerwono czarne, wstawianie, usuwanie N elementów itp) i 1.9 jest najszybszy, a dodatkowo używa 2x mniej pamięci od 1.8.6. JRuby z kolei używa 3x więcej od 1.8.6 (sic!). To mnie zaniepokoiło (cóż, java).
Za 10 miesięcy to prawdopodobnie będziemy przenosić się na 1.9. Rubinius w tej chwili jest szybszy (i to nie we wszystkich benchmarkach) od 1.8.6 (w zasadzie można powiedzieć, że w tej chwili jest to ta sama kategoria jeśli chodzi o speed), ale od 1.9 odstaje dosyć sporo (do niej tylko jruby się zbliża). Dopóki Rubiunius nie będzie mieć jita (którego do wersji 1.0 nie będzie) to możemy zapomnieć o prześcignięciu 1.9.
Wracając do samego tematu. Ja też chętnie widziałbym w użyciu prostych skryptów po stronie serwera (jak php). Nie ma co tłumaczyć, że vps są tanie. Bo są, ale zależy do czego. Jak chcę postawić prostą strnkę, z galerią, licznikiem to te kilkadziesiąt zł/miesiąc nie jest mało. Jak to ktoś ładnie napisał: php swoją popularność zawdzięcza przede wszystkim temu, że jest najprostszym rozwiązaniem do pisania prostych skryptów po stronie serwera (a od prostych skryptów do czegoś większego nie taka duża droga;)).
Gratuluję I bardzo ładnie się chwalić, bo chociaż subskrybuję bloga Ezry, to ten post jakoś mi umknął, zainstaluję pewnie u siebie ten plugin
Ulala, takie fooopa Przepraszam, ale sama pewnie wiesz najlepiej, że jesteś rzadkim przypadkiem na takich forach
Zabawne 
Wczoraj skończyłem pisać podobną aplikację na własne potrzeby Na pewno dużo prostsza (ma obsługę tylko railsów/php i będzie obsługiwała kilkanaście aplikacji), ale działa na tej samej zasadzie. Z tym, że ja sobie jeszcze ułatwiłem sprawę i podaje się tylko RAILS_ROOT i aplikacja sama wszystko wyciąga z pliku config/mongrel_cluster.yml (już miałem we wszystkich aplikacjach stworzone konfigi, a nie chciało mi się tego przepisywać). A czego używacie do monitoringu? Ja sobie bardzo chwalę goda
Może powinniśmy zrobić jakiś oddzielny topic o hoście megi :), czyżby w końcu zaświeciło słońce dla ‘małych’ ruby fanatyków, brak hosta nastawionego na rora był u nas bolączką, ja nie długo po testuję megiteam i mam nadzieję, że u was zostanę.
Mam pytanie - skąd ten termin 10 miesięcy? Nie mogę się doczekać dnia, gdy 1.9 wyjdzie z testów i stanie się środowiskiem produkcyjnym, liczę, że to będzie jakiś krok w oszczędnościach dla małych aplikacji ror i zamiast VPSów starczą hosty w stylu megiteam. Osobiście tego najbardziej zazdroszczę PHPowcom.
Tommy, 10 miesięcy było użyte jako przykład (drogus użył takiej jednostki ;)). Być może to będzie za 3, albo 12 miesięcy. Czas pokaże.
No właśnie Da się ułatwić życie użytkownikom? Da, kwestia motywacji ;>
“Tfórczość” własna
Zapraszam
Ja właśnie wczoraj założyłem konto i muszę przyznać, że byłem bardzo pozytywnie zaskoczony jak pomocna jest pomoc
Jeszcze muszę popatrzeć jak wygląda performance-wise, ale pierwsze wrażenie bardzo pozytywne.
[quote=drogus]Poprawić można by chociaż to, żebym mógł pod linuxem zrobić coś w stylu:
apt-get install nginx ruby postgresqli po prostu wrzucić skrypty rubiego do jakiegoś katalogu i odpalać tak jak php. Wiem, że jest Ramaze, Camping i inne tego typy lightowe frameworki, ale naprawdę czasami chcę po prostu zrobić coś naprawdę bardzo bardzo bardzo prostego i nie mam ochoty odpalać skryptu, który ma 10 linijek rubiego na oddzielnym porcie, ani robić sobie specjalnie aplikacji, żeby takie skrypciki uruchomić.[/quote]
http://www.modruby.net/en/
Niewiem jak to dziala - nigdy nie uzywalem. Nie podoba mi sie idea odpalania skryptow z poziomu serwera www (zwlaszcza takiej kobyly jak apache)
Przeciez mod_fastcgi mozna latwo ustawic zeby nie ubijal procesu - tylko jest znaczaca roznica ilu upchniesz PHPowcow a ilu RoRowcow jezeli bedziesz mial interpreter per user/aplikacja
Jeżeli mówisz o mod_fastcgi z Apache to nie każdy ma potrzebę używania tego serwera http to raz, a dwa, że nie jest on idealny (chociaż pewnie najlepszy) i np. w dużej firmie hostingowej w której pracowałam się nie sprawdził - pisali własne poprawki do niego. Problemem było np. to, że pojawiały się wyłączone spoza kontroli managera fastcgi procesy php, które trzeba było ubijać ręcznie. W skali w jakiej tak firma działa był to spory problem. Jak pisałam o managerze procesów to chodziło mi o takiego niezależnego od konkretnego serwera WWW - teraz jak ktoś chce skorzystać z Nginxa ma do wyboru skorzystać ze spawn-fcgi z Lighttpd albo napisać coś własnego. Chyba, że są inne, których nie znam
A to nie bylo tylko w przypadku apache-1.3.x ? Z tego co testowalem mod_fastcgi pod 1.3 to rzeczywiscie tak sie dzialo, natomiast mod_fcgid podczas testow nie pokazywal takich dziwnych zachowan.
A co do serwera WWW to nigdzie nie napisalem ze go kocham. Sam chetnie bym go wycial w pien na wszystkich moich maszynach, ale niestety spora czesc userow korzysta chociazby z mod_rewrite i jakos nie chce im sie/nie umieja uzywac innego mechanizu.
Komentarz Ezra Zygmuntowicz na stronie Coopera daje nadzieję:
Jest więc nadzieja, że doczekamy się dobrze zrobionego modułu Apacha dla Rubiego, co pozwoliłoby na stawianie aplikacji tak jak w php.
mod_ruby to teoretycznie taki sam hook na interpreter jak mod_php nie czaje o co wam chodzi z tym “tak jak w php” przeciez mod_php nie wspoldzieli kodu miedzy watkami. No kaman! To ze mod_ruby jest piekielnie wolny i zre pamiec jak Jozin z Bozin prazan to wina samego interpretera rubiego, lepiej nie odpalac na tym railsow ale przeciez nawet jesli sie odpali to dziala to calkiem dobrze, tyle ze potrafi jesc procesor po 90 % rails ma zbyt duzo plikow aby ladowanie wszystkiego tak jak w przypadku php co kazdy request mialo jakikolwiek sens, ale jeszcze komus trzeba cos malego, to mod_ruby stanowczo wystarzy.
Ciesze sie ze pojawi sie mod_rubinius, co do tego ze yarv to inna para kaloszy to mialem na mysli tylko to ze wlasnie realnie z tego korzystac bedzie sie za pol roku i to juz w rails 2.1, ja mam jeszcze sporo aplikacji w 1.2.x ktore musze utrzymac a ktore juz nieraz siegnely limitu jesli chodzi o pamiec na serverach, rubinius i mod_rubinius jest alternatywna dla rails 1.2.x i ruby 1.8 mri jesli wierzyc wykresom jakie Evan Phoenix przedstawial na rubyconf 2007 to jest szansa na to ze rubinius bedzie zjadal nawet o 50 % pamieci mnie, do tego lepszy gc jest tam zaimpementowany, well pozyjemy zobaczymy ja mam nadzieje ze rubinius dociagnie wreszcie do 1.0 w ciagu pol roku, jesli tak to jest to alternatywa dla 1.8.
Co do rubinius’a i JIT’a to jest to chyba planowane na wersje 2.0 a wiec pewnie nie wczesniej jak za poltora roku, minie jak z bicza strzelil a wtedy bye bye yarv, proxy balancer, welcome mongrel dla rails 2.x