Osobiscie wiele z tych rzeczy mi sie nie podoba, szczegolnie caly ten RESTful, ale to jest juz bardzo subiektywne czy ktos woli stary dobry MVC czy cos bardziej nowoczesnego. Pomysl z templatem typu index.html.erb albo index.csv.erb tez jest kiepski przypomina mi to bardzo nazwienictwo plikow w frameworkach opartych o php 5.
Jakie sa wasze odczucia ? Ja sadze ze Rails zbyt mocno brnie w kierunki ficzerow i wodotryskow a za malo w kierunku optymalizacji (np ActiveRecord). Jesli Rails 2.0 nie okaze sie wydajniejsze od rails 1.2.3 to nie planuje migracji. Tymbardziej jesli RESTful bedzie jedyna droga dla aplikacji w rails, chocaiz zapewne powstana pluginy ktore beda pozwalaly na krozystanie ze starego modelu routes.
DHH podczas keynote na ostatnim RailsConf powiedział, że Rails 2.0 paradoksalnie nie wprowadza nowych rozwiązań - “jesteśmy zadowoleni z tego co mamy”. Ja odniosłem wrażenie, że zmiany są raczej kosmetyczne i nie powinny stwarzać problemów podczas migracji. Z samej wydajności (nadal) jestem zadowolony
Przeglądnąłem także changelog i też wydaje mi się, że rewolucji jakiejś nie ma. Nie przywołujmy ciągle tematu wydajności, bo będzie się to ciągnąć za Rubym całe życie ;). Kolejne wersje Rubiego będą prawd. dużo szybsze (http://groups.google.com/group/ruby-talk-google/browse_thread/thread/9b37efdac11b474e/da574987880fead6). Nie wiem czy wersja 1.9 to już jest ta z YARVem, ale wygląda na to, że odpowiednio skompilowany Ruby w wersji 1.9 może być szybszy 3x albo więcej od dotychczasowej wersji.
Odnośnie wydajności: Ola Bini przewiduje, że implementacja Matza (MRI) może zostać wyparta przez Rubiniusa i/lub JRuby, właśnie ze względu na wydajność.
Nie testowalem jeszcze rubiniusa ale przed jruby jeszcze chyba dluga droga: http://pastie.caboo.se/106841
1 scaffold, 30 kolumnowa tabela, widok formularza… ponad 9x wolniejsze jest jruby
Pak, zobacz na ten wpis: http://ola-bini.blogspot.com/2007/10/mystery-expos-on-jruby-performance.html .
Wygląda na to, że w benchmarkowych testach JRuby jest szybszy, ale w samych railsach nie :). Ola Bini napisał, że gdzieś jest bottleneck, który to powoduje i trzeba go znaleźć, ale nie jest to takie proste i na razie nie wiedzą co jest przyczyną takiego stanu rzeczy :).
EDIT:
I jeszcze na dokładkę:
JRuby szybszy od MRI i trochę wolniejszy od YARV (btw, YARV to wersja 1.9 czy 2.0?). Może być na prawdę ciekawie :). Do tego Rubinius :).
Pak, uruchamiasz w trybie development czy production?
Mysle ze bootleneck to rhtml i wszystko zwiazane z widokiem. Widac to wyraznie przy wywolywaiu jakichkolwiek skryptow w JRuby.
jruby -S ./script/server, jruby -S ./script/generate, jruby -S gem install rails te wszystkie komendy dzialaja wyraznie wolniej, a skoro w benchmarkach jruby wypada lepiej to by tylko oznaczalo ze po prostu zaladowanie calego JRUBY, a potem sparsowanie skryptu i przeniesienie go na bytecode jest wolniejsze niz ta sama operacja z wykorzystaniem implementacji w c, natomiast wywolanie i optymalizacja bytecodu daje wieksze przyspieszenie w benchmarkach.
Rails nie robi cache plikow rhtml, sa zawsze odczytywanie bezposrednio z dysku, nawet podczas produkcyjnego dzialania aplikacji mozna podmienaic pliki widokow. JRuby pewnie nie radzi sobie po prostu z tym tak dobrze jak cruby.
Jednym slowem problemem jest tutaj architektura Rails. Ktore oferuje w produkcyjnym dzialaniu tylko cachowanie samych klas. Natomiast Widok to juz bezposrednie operacje dysk->ruby<->pamiec cache<->mongrel/fcgi/apache
Wywołania w stylu ‘jruby plik.rb’ trwa długo bo ładuje się maszyna wirtualna javy, a to jest dosyć potężne bydle. Benchmarki wypadają lepiej, gdyż mierzą tylko i wyłącznie sam skrypt, gdzie środowisko jrubiego jest już załadowane. Jednak to nie powinno stanowić problemu, gdyż uruchomienie mongrela, czy innego servera obsługującego railsy wykonuje się raz.
[quote]Jednym slowem problemem jest tutaj architektura Rails. Ktore oferuje w produkcyjnym dzialaniu tylko cachowanie samych klas. Natomiast Widok to juz bezposrednie operacje dysk->ruby<->pamiec cache<->mongrel/fcgi/apache
Co myslicie o takiej teorii ?[/quote]
Rozumiem, że chodzi Ci o to, że plik szablonu .rhtml musi zostać przetworzony do kodu rubiego, odpowiednio sparsowany przez JRuby (co według Ciebie trwa wolno) i potem odpalony (a to szybciej). Jest to jakaś teoria, trzeba by ją sprawdzić :). Aczkolwiek wydaje mi się, że JRuby nie powinien odstawać od MRI w tym przypadku, ale kto wie. W komentarzach do podanych przeze mnie linków, niektórzy piszą, że być może to kwestia obsługi regexów, które są silnie wykorzystywane przez railsy.
Można wykonać test, który nie wykorzysta .rhtml (render :text => ‘qwe’) i porównać czy będzie podobnie jak z .rhtml.
Na blogu Ola Bini pojawił się post, w którym wskazuje on dokładnie pierwszą z możliwych przyczyn słabej wydajności JRuby on Rails: i jest nią… implementacj each_line, która korzysta z wyrażenia regularnego /.*?\n/ W MRI wykonanie wyrażenie tego rodzaju zależy liniowo od długości łańcuch, w JRuby - jest to zależność kwadratowa
Zamiana implementacji na /[^\n]\n/ znacząco poprawia wydajność each_line. Niestety nie jest to panaceum na problemy JRuby on Rails.
Swoją drogą gdybym był implementatorem each_line intuicyjnie wybrałbym to drugie wyrażenia…
Uwaga: ponieważ 2.0.0 zawiera jakiś bug należy upewnić się, że ściągamy 2.0.1.
Niestety dla nas - forumowiczów - oznacza to, że będziemy mieli sporo problemów typu: “Robie jak w AWD with Rails, etc. a mi nie działa”, bo ludzie będą ściągać najnowszą wersję nie zastanawiając się, czy to jest 1.2, czy 2.0.
Ja jeszcze pewnie przez najblizsze pol roku pozostane przy 1.2.6, ostatnio sporo mowi sie o konkurencyjnych frameworkach takich jak np Merb, ktory jest znacznie bardziej wydajny od Rails, wiec gdy stawiam sobie pytanie - W ktora strone Rails 2.0 moze teraz pojsc? Sadze ze pojdzie wlasnie w strone wydajnosci.
A czy ktos moze widzial jakis tutorial odnosnie migracji ? Tak zeby mozna bylo latwo spojzec na liste “todo”, co trzeba zmienic na co itd ? Mnie generalnie idea restful totalnie odrzuca wiec zupelnie jej nie sledzilem. Stad moje drugie pytanie. Czy Rails 2.0 wymusza RESTful czy mozna uzywac normalnie MVC jak poprzednio ?
Z gory dzieki za odpowiedz
Pozdrawiam (leniwy:) Pawel
Byłbym bardzo zdziwiony gdyby tak było. Wątpię, że wymusza ale kilka rzeczy ułatwia (kilka przykładów na www.railscasts.com - ostatnich 5 odcinków jest o ficzerach z 2.0)
Nie testowałem jeszcze 2.0 i pewnie przez jakiś czas pozostanę przy poprzedniej wersji.
Jeszcze jedno, dla mnie najbardziej zauważalną zmianą było (gdy jakiś czas temu korzystałem z HEAD’a) domyślne korzystanie z ciasteczek jako session storage, to pewnie będzie pierwsza rzecz, którą zauważysz po upgrade. Ułatwia życie bo nie musisz sam dbać o czyszczenie sesji, jest też szybsze ale zastanowiłbym się kilka razy zanim z tego skorzystam w swojej aplikacji.
Wiecie może w jaki sposób zapewniane jest bezpieczeństwo danych przetrzymywanych po stronie kilenta w przypadku użycia cookies do sesji? Np administrator=true zapisane w sesji.
A co za roznica czy ktos zrobi hijacking zmiennej administrator czy user_id ? Jak dobrze sie wstrzeli to i tak trafi na konto o wiekszych/innych uprawnieniach.
Wiem, że takich rzeczy nie powinno się raczej trzymać w sesji Użyłem bezpośrednio przykładu z posta DHH http://weblog.rubyonrails.org/2007/12/7/rails-2-0-it-s-done [quote]If, however, you are planning on storing the nuclear launch codes in the session, the default cookie store is a bad deal. While they can’t be forged (so is_admin = true is fine), their content can be seen[/quote]
, żeby lepiej wyjaśnić o co mi chodzi w pytaniu:)
wiec zupelnie jej nie sledzilem. Stad moje drugie pytanie. Czy Rails 2.0 wymusza RESTful czy mozna uzywac normalnie MVC jak poprzednio ?