Vlákno názorů k článku
Jan Minárik: S Rails vyvíjíme efektivněji
4. 7. 2007 7:41
rychlost oproti PHP aplikacím
zajímalo by mne srovnání v rychlosti oproti webovým aplikacím v PHP, jelikož zastávám názor že cokoliv co je v RRails musí být pomalejší než když je to jen v PHP (hlavně mne zajímá serverová zátěž)
aura:97
4. 7. 2007 8:32
Re: rychlost oproti PHP aplikacím
Zkousel jsem testovat rychlost ruby proti PHP a v ramci mych testu bylo asi sestkrat rychlejsi. Ale pozor, to neni vubec smerodatne, jednalo se jen o velmi omezeny okruh testu, takze to o nicem nevypovida a o tom, jak rychle to bezi na serveru teprve ne. Ale nicmene nemyslim si, ze by problem Ruby byla rychost, to ani ne, spise pamet. Klasicke reseni, tj. mongrelovy cluster si vyzere skutecne hodne. Ale na druhou stranu to se kompenzuje vetsimy zisky za aplikace, ktere vyvijite vyrazne rychlejsi.
pkm (neregistrovaný)
4. 7. 2007 10:54
Re: rychlost oproti PHP aplikacím
No tak interpreter Ruby asi nebude z nejrychlejších. Ale to vůbec nevadí, protože největší brzdou webových aplikací je databáze. Poskládat výslednou stránku je sranda, ale SELECT nad jedenácti tabulkami, z nichž některá má třeba mega záznamů, to není žádná sranda.
uživatel si přál zůstat v anonymitě
9. 7. 2007 18:42
Re: rychlost oproti PHP aplikacím
Krome toho, ze interpret ruby je jeden z nejpomalejsich (orientacne viz. napr. http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all), tak RoR rychlosti zrovna dvakrat neprida. Jako hlavni problem vidim jejich ActiveRecord, ktery si s optimalizaci zrovna hlavu nedela (ovsem neznam nejnovejsi verzi), do databaze posila obrovske mnozstvi dotazu, kde nejsou potreba. Takze v kritickych castich jsem byl nucen se vykaslat na pekne, ciste a kratke zapisy v Ruby a nahradit je stejne osklivymi a slozitymi lec rychlymi SQL prikazy.. :( Pokud je potreba neco pocitat mimo databazi, tedy v pripadech, kdy jde o hruby vypocetni vykon Ruby, tak je rychlost interpretu take znatelna.. Jinak s vetsinou "PR reci", ktere se tykaji efektivity programovani (koneckoncu i zabavy pri psani;), vicemene souhlasim a verim, ze se RoR bude dal s postupem jeho vyvoje zefektivnovat a prichodem Ruby 2.0 se situace dal zlepsi..
kb (neregistrovaný)
4. 7. 2007 12:54
Re: rychlost oproti PHP aplikacím
Ja ale nechapu to neustale srovnavani s PHP. I na tech videich co byly v tom nejakem blogu hned po konferenci. Srovnavate framework a jazyk, coz je tak trochu blbost. Pokud zacnete psat aplikace from scratch v ruby i v php bude s tim spousta prace. Srovnavejte spise Symfony a RoR. To uz by bylo porovnatelne. Trochu symfony znam a myslim, ze s nim by se dali taky rychle a efektivne vyvyjet aplikace stejne jako v RoR (ale nechci zakladat flame, jen nazor). Navic kdyz se dva hadaji treti se smeje :) (Python?).
P.S. po te konferenci se zacinaji objevovat nehorazne tendecni clanky opevujici RoR. Tim nerikam, ze jsou spatne, samotneho me laka je vyzkouset. Jen dojem.
P.S. po te konferenci se zacinaji objevovat nehorazne tendecni clanky opevujici RoR. Tim nerikam, ze jsou spatne, samotneho me laka je vyzkouset. Jen dojem.
uživatel si přál zůstat v anonymitě
4. 7. 2007 14:48
Re: rychlost oproti PHP aplikacím
Jasně, je to jazyk vs framework.
Co se týče jazýků, tak Ruby je krásný objektový jazyk se sílou Smalltalku a přístupnou syntaxí. PHP je odporný nekonzistentní bastl, který ale na vývoj webů není k zahození :-)
Co se týče jazýků, tak Ruby je krásný objektový jazyk se sílou Smalltalku a přístupnou syntaxí. PHP je odporný nekonzistentní bastl, který ale na vývoj webů není k zahození :-)
Biktop (neregistrovaný)
5. 7. 2007 13:14
Re: rychlost oproti PHP aplikacím
No... Já bych nepřeháněl. Na Smalltalk se to rozhodně nehrabe. Nebo neznáte Smalltalk.
4. 7. 2007 9:10
Re: rychlost oproti PHP aplikacím
Hmm, já mám zase z PHP pocit, že bude pomalejší, protože je "one-shot", při každém požadavku musí zpracovat skoro všechno znovu. Oproti tomu dlouhoběžící proces (nějaký aplikační server) může výrazně těžit z toho, že si bude data uchovávat v paměti. "Tvrdá čísla" samozřejmě nemám.
Problém je v tom, že aby člověk získal "tvrdá čísla" musí mít nějakou složitější úlohu a většinou nemá čas ji napsat ve dvou jazycích. Syntetické testy je možné nastavit tak, aby vyhrával libovolný z jazyků.
PS: V Ruby nepíšu, srovnávám PHP a Python.
Problém je v tom, že aby člověk získal "tvrdá čísla" musí mít nějakou složitější úlohu a většinou nemá čas ji napsat ve dvou jazycích. Syntetické testy je možné nastavit tak, aby vyhrával libovolný z jazyků.
PS: V Ruby nepíšu, srovnávám PHP a Python.
4. 7. 2007 10:21
Re: rychlost oproti PHP aplikacím
PHP se da spustit jako FastCGI. Proto se pak vsechno nemusi zpracovavat znovu ale zavola se jen program v pameti. Dalsi vyhodou FastCGI je i to, ze kdyz si program navaze spojeni na DB, tak si ho ten program uchova tak dlouho, jak je to nastavene v DB serveru. Ono navazovani spojeni s DB je take dosti casove narocne a zatezuje to navic jak aplikacni tak DB server. Proto doporucuji u velkych projektu pouzivat FastCGI technologii. FastCGI ma podporu nejen v PHP, ale i v Perlu, Pythonu a dalsich jazycich.
Palo (neregistrovaný)
4. 7. 2007 15:17
Re: rychlost oproti PHP aplikacím
> Proto doporucuji u velkych projektu pouzivat FastCGI technologii.
A ja odporucam pre velke projekty Javu.
A ja odporucam pre velke projekty Javu.
Rejpal (neregistrovaný)
4. 7. 2007 15:36
Re: rychlost oproti PHP aplikacím
Nebo ještě lépe Common Lisp.
hisaak (neregistrovaný)
4. 7. 2007 16:42
Re: rychlost oproti PHP aplikacím
Nic proti FCGI, ale ten pool databazovych spojeni lze snad na normalni platforme resit i jinak, ne?
Ivan (neregistrovaný)
4. 7. 2007 22:54
Re: rychlost oproti PHP aplikacím
Ono moc reseni neexistuje. PHP, Perl i Python maji problem v tom, ze jsou postavene na
knihovnach napsanych C(C++), takze i kdyby nakrasne byly jejich interpretry multivlaknove,
tak alesom jedna knihovna na kterou maji binding nebude thread-safe. I kdyby i bylo vsechno thread-safe tak budou knihovny obsahovat memory leaky. Multivlaknovost PHP je jen chimera. Threaded worker Apache2 je uz hodne dlouho unstable a v kombinaci s PHP asi nikdy fungovat nebude. Akoliv jsem byl hodne dlouho odpurce JAVY, tak jsem musel uznat, ze v kombinaci s DB Oracle jsou aplikacni servery postavene na JAVE mnohem vykonejsi nez cokoliv postavene na Apache. Pokud totiz otevirate a zavirate 200 DB session za sekundu tak je uplne jedno
jestli mate aplikaci napsanou v JAVE nebo z assembleru.
knihovnach napsanych C(C++), takze i kdyby nakrasne byly jejich interpretry multivlaknove,
tak alesom jedna knihovna na kterou maji binding nebude thread-safe. I kdyby i bylo vsechno thread-safe tak budou knihovny obsahovat memory leaky. Multivlaknovost PHP je jen chimera. Threaded worker Apache2 je uz hodne dlouho unstable a v kombinaci s PHP asi nikdy fungovat nebude. Akoliv jsem byl hodne dlouho odpurce JAVY, tak jsem musel uznat, ze v kombinaci s DB Oracle jsou aplikacni servery postavene na JAVE mnohem vykonejsi nez cokoliv postavene na Apache. Pokud totiz otevirate a zavirate 200 DB session za sekundu tak je uplne jedno
jestli mate aplikaci napsanou v JAVE nebo z assembleru.
Rejpal (neregistrovaný)
5. 7. 2007 1:41
Re: rychlost oproti PHP aplikacím
Hmm, ale nakonec je všechno napsané v Cčku, ve kterém mohou být memory leaky. V JITu můžou být chyby. Když mohou být leaky nebo chyby v PHP nebo Apachi, proč by nemohly být v Javě? Nebo v těch mamutích aplikařních kontejnerech? Nebude fígl v tom, že když je něco hodně používané (Java, Apache, PHP), budou v tom ty chyby vychytané? ;-)
Věta "i kdyby nakrasne byly jejich interpretry multivlaknove, tak alesom jedna knihovna na kterou maji binding nebude thread-safe" je mírný úlet, protože to zcela jistě nutné není - nebo snad překročíte stín vlastní mlčenlivosti a prozradíte nám, kterážeto knihovna je naprosto nevyhnutelná a přitom thread-unsafe?
Věta "i kdyby nakrasne byly jejich interpretry multivlaknove, tak alesom jedna knihovna na kterou maji binding nebude thread-safe" je mírný úlet, protože to zcela jistě nutné není - nebo snad překročíte stín vlastní mlčenlivosti a prozradíte nám, kterážeto knihovna je naprosto nevyhnutelná a přitom thread-unsafe?
Ivan (neregistrovaný)
5. 7. 2007 10:39
Re: rychlost oproti PHP aplikacím
Znate nejaky xslt procesor ktery nema memory leaky? Treba o libxml2 jeji autor napsal neco v tom smyslu ze: "Nepouzivame staticky promenny, takze doufame ze nase knihovna je TS.
Nemame ale cas to testovat".
Nemame ale cas to testovat".
aura:100
5. 7. 2007 10:03
Re: rychlost oproti PHP aplikacím
Možná bych to upřesnil - mpm_worker v Apache je stable už dost dlouho. S mod_php to asi opravdu nikdy nebude, to by to vývojářům PHP muselo přestat být jedno. Nějakou dobu používáme Apache 2.2 jako mpm_worker v kombinaci s FastCGI PHP a Mongrelem a funguje to výborně.
Ivan (neregistrovaný)
5. 7. 2007 10:45
Re: rychlost oproti PHP aplikacím
Dekuji a opravu. Muj predchozi prispevek berte prosim s nadsazkou. Ton jakym je to napsane je castecne zpusoben frustraci zpusobenou hledanim race a leaku v knihovnach napsanych v Cecku.
