fastcgi + ruby on rails vs mod_php

[bassul]

Pornind de la subiectul acesta:
http://gazduire.info/forum/index.php/topic,1985

as vrea sa apreciem cat de cat cat este de eficient ruby in mediu shared, sa spunem o comparatie Apache + fastcgi + ruby on rails vs Apache + mod_php. Aceasta este din cate stiu cea mai eficienta combinatie pentru cele 2. Pe google am gasit ceva comparatie intre framework-uri, dar se plangeau ca e biased in favoarea Ruby.

Cine are mai mult insight in asta, eventual experienta unui site foarte incarcat facut cu Ruby...

[emi25]

nu am incercat Rubi, dar mi se pare publicitate.
De ce nu vin cu solutii ? servere cu zeci de mii de useri ?
Adica uite: noi putem mai bine.

eu nu ii vad. voi vedeti pe careva ?

Tot vorbind de performanta, apache nu e singulul server, si nici cel mai performant, ok, o fi el fiind testat si res testat, e stabil, din punctul asta de vedere e ok, dar mai exsista si lighttpd, tot asa un server si pe linux si pe windows, pe care l-am testat. am citit ca unii ai testat apache contra lighttpd, si acesta a surclasat orice record.
Faceti teste. 

[Tomoiaga]

Pai, ii dai 100 cereri simultan pe apache la un site in ruby. Geme....
Nu se pot face comparatii. Mai demult era p1 la 133 Mhz, cum ar merge unul acum cu clientii de pe un p4 sau altceva mai bun ?
Mie nu imi plac procesele in plus. Sunt convins ca performantele sunt foarte slabe in comparatie cu apache+mod_php dar puterea de calcul creste.
Oricum, daca vrei sa faci o comparatie, o faci de distractie, ca sa vezi ce server iti trebuie pentru ruby. Aici vine avantajul ca nu o sa ai atatia clienti ca la php ci mult mai putini si o sa duca un server normal. Nu se complica nimeni cu ruby inca. A vazut cineva "Idiocracy" ?
php ai tone de porcarii, ruby nu prea ai, foarte putini stau sa invete ruby etc.

[bassul]

Ruby on rails e un framework destul de bine gandit, din cate am inteles de la cativa prieteni care sunt fani. Avantajele unui framework ? Mai putine bug-uri in codul final, forteaza putin structura (MVC probabil) a unui proiect.

PHP-ul are mai multe framework-uri, si multi incepatori nu folosesc niciuna din ele. Deci Ruby are ceva avantaje din punctul de vedere al programatorului.

emi25, lighttpd e folositor pentru servere dedicate, pentru hosting shared are minusuri (lipsa .htaccess, per-virtual-host configuration ?, integrare control panel). De aceea am adus in discutie cele doua sub Apache.

Totusi n-am vazut nici un benchmark cat de cat bine facut cu 2 aplicatii, similare ca si cod, rulate pe acelasi computer, cu ab sau ceva similar.

[Tomoiaga]

pai or sa faca de cacao ruby-u la viteza, de asta nu au facut inca.

[Adrian Andreias]

lighthttpd e forte bune pentru servire de media/continut static. Altfel apache incarca toate mod-urile perfect nenecesare cand serveste o imagine de ex.

Personal nu sunt fan ROR. E un mare progress in dezvoltarea de aplicatii web, dar se poate mai bine. Limbajul cat si fx-ul au niste decizii design cu care nu sunt de acord, sunt exact pe dos la unele principii din The Zen of Python.

Altceva ce nu imi place, e buzz-ul ce s-a facut in jurul ROR. Aparitiile lui prin presa ies din sfera programarii. Se scriu articole business cu o gramada de abureli, in loc sa ramana in sfera tehnica, si sa prezinte fapte, nu hype; alte articole incearca sa te convinga ca ajunge sa te pricepi la HTML si atunci o sa te descurci lejer si cu ROR. Foarte de fals de altfel, samburele fiind doar ca are pe a locuri o sintaxa simplificata si mai accesibila, a la BASIC.

Pe de alta parte, exista soft cu adevarat de apreciat construit pe ROR.

Deci nu e numai buzz, e o tehnologie ce merita luata in seama.

[dan goes online]

pai or sa faca de cacao ruby-u la viteza, de asta nu au facut inca.

E chiar asa de greu pt unii sa priceapa ca timpul utilizat de un programator costa mai mult decat timpul utilizat de un procesor?
2 zile de programare in plus ar costa pe putin 160 EUR pt fiecare programator (nu am inclus taxele ce trebuie platite la stat).

Intr-o luna, diferenta de bani dintre crearea si intretinerea unei aplicatii in PHP versus RoR/Django ar putea depasi 1000 EUR. Din astia 1000 iti permiti sa dai 500 in plus pt un procesor mai bun si iese profit de ambele parti: dezvolator & cumparator!

PS: nu sunt fan RoR (ba chiar Django imi place mai mult si in testele de viteza cam bate si PHP-ul cu orice framework MVC si RoR-ul). Despre solutiile in Java sau .Net nu ma pronunt fiindca nu stiu.


Revenind, despre nginx + n * mongrels ce parere aveti? Chiar is curios cum s-ar compara acest setup vs mod_php

[Adrian Andreias]

E chiar asa de greu pt unii sa priceapa ca timpul utilizat de un programator costa mai mult decat timpul utilizat de un procesor?
2 zile de programare in plus ar costa pe putin 160 EUR pt fiecare programator (nu am inclus taxele ce trebuie platite la stat).

Intr-o luna, diferenta de bani dintre crearea si intretinerea unei aplicatii in PHP versus RoR/Django ar putea depasi 1000 EUR. Din astia 1000 iti permiti sa dai 500 in plus pt un procesor mai bun si iese profit de ambele parti: dezvolator & cumparator!

Corect, asta e tendinta. Hardware-ul se ieftineste, lucrul manual (eventual) se scumpeste.
Mai e o problema: inertia si frica de nou. Unii clienti sunt imposibil de convins ca Django+Python e calea, si nu PHP.

PS: nu sunt fan RoR (ba chiar Django imi place mai mult si in testele de viteza cam bate si PHP-ul cu orice framework MVC si RoR-ul). Despre solutiile in Java sau .Net nu ma pronunt fiindca nu stiu.

Din nou corect, Django e varianta mea preferata .
Este o comparatie Java vs Django la performanta pe user mailing listul Django. Din cate am inteles Java cu JSP ar ocupa mai putina memorie, dar nu sunt convins ca era facut un setup de server optim. Java oricum nu-mi place din motive subiective, dar sunt si motive obiective (vedeti primul video: http://seankelly.tv/videos ).

[Tomoiaga]

E chiar asa de greu pt unii sa priceapa ca timpul utilizat de un programator costa mai mult decat timpul utilizat de un procesor?

Da costa, pentru ca daca unul freaca meciu pe un server shared pleaca toti deci eu pierd mult mai mult decat cel cu site-ul.
In plus, clientul nu e programatorul in 90% din cazuri, deci pe el il intereseaza cat mai eftin nu cat mai optim etc pentru ca nu vrea sa dea bani. A.s.o. Deci nu noi 2 trebuie sa discutam ce conteaza cel mai mut ci fiecare in parte cu clientul.

[Adrian Andreias]

Eu ma gandeam la solutii mai serioase; unde e vorba de dedicate si nu programatori de duminica

[bassul]

Daca vorbim de solutii serioase nu cred ca se pune problema ca PHP-ul sa fie mai slab ca Ruby ca si productivitate. Framework-uri bune exista si pentru PHP, si oricum cam orice proiect mai mare nu se face cu cod scris de la 0.

Poate cativa cunoscatori Ruby sa ma contrazica, desi cred ca cel mai mult timp la programarea avansata se pierde la debugging, si un limbaj mai simplu e de obicei mai permisiv, ceea ce face mai greu debugging-ul.

[Tomoiaga]

corect, eu discutam la general. Ca si viteza e mai rapid PHP, dar cum zicea dan goes online (si am priceput) nu mai conteaza timpul de raspuns daca vorbim de dedicat si duce oricum.

[dan goes online]

Da costa, pentru ca daca unul freaca meciu pe un server shared pleaca toti deci eu pierd mult mai mult decat cel cu site-ul.
In plus, clientul nu e programatorul in 90% din cazuri, deci pe el il intereseaza cat mai eftin nu cat mai optim etc pentru ca nu vrea sa dea bani. A.s.o. Deci nu noi 2 trebuie sa discutam ce conteaza cel mai mut ci fiecare in parte cu clientul.

Pai, man, de ce nu citesti tot ce am scris eu? Uite, iti extrag din paragraf: "Din astia 1000 iti permiti sa dai 500 in plus pt un procesor mai bun" Deci clientul isi va permite sa plateasca in plus pt webhosting!

(nu-mi zi ca tie nu ti-ar conveni sa ai 100 de clienti care platesc cate $50/luna pt RoR decat 1000 de clienti care platesc cate $1.99/luna pt PHP )


Si daca tot era comparatia (la care deocamdata nimeni nu-i stie rezultatul) intre fastcgi vs mod_php, poate ar trebui adaugat si mod_python (care, din cate tin eu minte, este/era recomandat de cei de la Django)

[dan goes online]

corect, eu discutam la general. Ca si viteza e mai rapid PHP, dar cum zicea dan goes online (si am priceput)

Oricum la majoritatea siturilor mari, problemele apar mai degraba la baza de date decat la viteza de executie a codului PHP/Python/Ruby.

[Adrian Andreias]

Parerea mea este ca PHP e depasit de situatie. Si e vorba de decizii majore de design, pe langa multitudinea de maruntisuri. As putea sa scriu un roman pe tema asta.

Performanta mai buna, nici vorba:
http://wiki.rubyonrails.com/rails/pages/Framework+Performance

Intre timp pe multe proiecte se continua cu PHP si multe proiecte noi se incep tot pe PHP, din inertie.