Spouštíme letní ORM test PHP frameworků
V současné době je k dispozici veliké množství různých PHP frameworků, které usnadňují práci při tvorbě webových aplikací. Všechny mají specifické vlastnosti a ne vždy je úplně snadné zvolit ten pravý. Problém nastává ve chvíli, kdy chce programátor najít nějaký hromadný srovnávací test a podle něj se rozhodnout, který framework využít.
Seriál: ORM test PHP frameworků (9 dílů)
- Spouštíme letní ORM test PHP frameworků 3. 7. 2013
- ORM test PHP frameworků – CakePHP, CodeIgniter 10. 7. 2013
- ORM test PHP frameworků – DooPHP, Jelix 17. 7. 2013
- ORM test PHP frameworků – Kohana, Laravel 26. 7. 2013
- ORM test PHP frameworků – Nette, Prado 31. 7. 2013
- ORM test PHP frameworků – Qcodo, Recess 7. 8. 2013
- ORM test PHP frameworků – Seagull, Symfony 14. 8. 2013
- ORM test PHP frameworků – Yii, Zend Framework 21. 8. 2013
- ORM test PHP frameworků – PHP, závěr 28. 8. 2013
Nálepky:
Úvod
Téměř každý, kdo vytváří větší webové aplikace, pravděpodobně používá nějaký z aktuálně dostupných frameworků. Jedním z hlavních parametrů při jeho výběru je samozřejmě vkus daného jedince (skupiny) a zkušenosti v určitém programovacím jazyce. Ale co když se najde programátor, který chce vytvořit aplikaci a neví, jaký framework použít? Nejspíš se nebude učit s každým a následně si vybere ten, který mu vyhovuje nejvíce, ale pokusí se na internetu najít testy a srovnání, aby si zvolil dle jeho aktuálních potřeb. Hlavním parametrem při tomto hledání by byl nejspíše výkon, rychlost a paměťová náročnost. Protože patřím přesně do této skupiny a nepodařilo se mi najít požadovaný aktuální srovnávací test, rozhodl jsem se, že jeden takový vytvořím. Dle průzkumů a různých názorů dostupných na internetu, jsem vybral 14 nejznámějších PHP frameworků (jejich přehled najdete na konci tohoto článku) a pokusil se je porovnat na základě jejich rychlosti a náročnosti při komunikaci s databází.
Každý framework je alespoň trochu odlišný, ať už se jedná o použité programovací jazyky nebo strukturu uspořádání zdrojových souborů. Hlavním aspektem jejich rozdílnosti je ale množství dostupných funkcí a knihoven a případná rozšiřitelnost. Jestliže aplikace používá knihovny, které nepotřebuje přímo k běhu dané aplikace, tak to může mít negativní dopad na její rychlost.
Většina dostupných testů se zabývá pouze vypsáním věty „Hello world“ nebo jednoho jednoduchého SQL příkazu, z tohoto důvodu bylo použito spíše zátěžové testování a různé příkazy.
Konfigurace testu
Test jsem prováděl na dvou vlastních počítačích, a to tak, že na jednom běžel lokální server a na druhém program pro testování. Tuto konfiguraci jsem zvolil, aby test nebyl ovlivněn výkyvy připojení nebo rozdílným zatížením použitého hostingu a aby testovací program neovlivňoval výkon počítače se serverem.
K testování byly použity:
Stolní počítač se serverem:
- Procesor: Intel(R) Core(TM)2 Duo E8400, 3.00 GHz
- Paměť: 8.0 GB DDR2
- HDD: 5400 RMP, SATA
- OS: Ubuntu Server verze: 12.04.1 LTS x86
- Apache HTTP server ve verzi 2.2.22
- MySQL klient ve verzi 5.5.24
- PHP 5.3.10
Notebook s testovacím programem:
- Typ: ASUS UL80VT
- Procesor: Genuine Intel(R) CPU U7300, 1.3GHz
- Paměť: 4.0 GB DDR3
- HDD: 5400 RMP, SATA
- OS: Microsoft Windows 7 Professional x64, Service Pack 1
Další nástroje:
- Wi-Fi router: TP-LINK TL-WR340GD
- Testovací program: Apache JMeter 2.8 (r1393162)
- Databáze Sakila
Průběh testu
Jak bylo zmíněno výše, test byl prováděn na dvou počítačích. Nejprve jsem nainstaloval a nakonfiguroval Ubuntu server s Apache a MySQL na stolním počítači. Následně jsem nainstaloval databázi Sakila a poté jsem postupně vytvářel jednotlivé projekty (aplikace) tak, aby se vzájemně neovlivňovaly.
Každá aplikace měla za úkol:
- Vypsat seznam všech zákazníků (tabulka customer)
- Vytvořit nového herce (tabulka actor) s unikátním ID a jménem a příjmením dle požadavku
- Zkontrolovat existenci záznamu a následně editovat vytvořeného herce vybraného dle ID
- Zkontrolovat existenci záznamu a následně smazat vytvořeného herce vybraného dle ID
Pro každou funkci byla vytvořena samostatná stránka obsahující funkcionalitu určenou výhradně pro zpracování daného požadavku.
Nastavení programu Apache JMeter
K testování jsem využil testovací program Apache JMeter, který byl pro každý projekt nastaven tak aby generoval 30 uživatelů s ramp-up periodou 10 sekund. Což znamená, že během každé vteřiny se přihlásí 3 noví uživatelé.
Následně byla definována smyčka (loop), ve které každý uživatel prováděl dané úkoly. Počet opakování byl nastaven na 100. V tomto cyklu byly zadávány jednotlivé příkazy přes „HTTP request“, ve kterém byla definována adresa dané stránky a případná data posílaná přes POST příkaz.
Za účelem generování jednoznačných identifikátorů a rozlišení kroků programu, byly vytvořeny dvě počítadla (counter). Počítadlo uživatelů (UserCounter) bylo umístěno před smyčku a počítadlo požadavků (RequestCounter) bylo závislé na daném uživateli a nacházelo se uvnitř daného cyklu. Pro vygenerování ID sloužila matematická funkce „jexl“ využívaná v programu Apache JMeter.
${__jexl(${UserCounter}*1000+${RequestCounter})
Tento vzorec vynásobí pořadí aktuálního uživatele číslem 1000 a přičte k němu hodnotu počítadla cyklů. Například pro 12. uživatele v jeho 54. kroku je vygenerováno ID = 12054.
Pro čtení výsledků daných testů jsem využíval grafy průběhu(Spline Visualizer, Graph Results) a detailnější tabulkové zobrazení zjištěných údajů (Aggregate Report).
Všechny testy byly zaměřeny výhradně na rychlost zpracování jednotlivých požadavků.
Podrobnější průběh testů
1. TEST – Výběr záznamů (SELECT)
Každý uživatel v každém jednotlivém kroku provedl výběr celé tabulky zákazníků a nechal si vypsat informace o každém záznamu (ID, jméno, příjmení).
– Pro jeden každý projekt bylo provedeno 3000 těchto výpisů (100 cyklů pro 30 uživatelů)
2. TEST – Vytvoření nového záznamu (INSERT)
Každý uživatel v každém kroku přidal do databáze záznam o novém herci s unikátním identifikátorem a jménem a příjmením složeným z pořadového čísla uživatele, číslem kroku a označením pro danou buňku.
Př. 12. uživatel ve svém 52. Kroku vložil do tabulky údaje:
- ID: 12052
- First_name: FirstName_U12_R52
- Last_name: LastName_U12_R52
– Pro jeden každý projekt bylo provedeno 3000 těchto vložení (100 cyklů pro 30 uživatelů)
3. TEST – Úprava záznamu (UPDATE)
Každý uživatel zkontroloval dostupnost svých údajů v databázi definovaných aktuálním krokem, a to v závislosti na unikátním ID generovaného dle pořadí uživatele a na aktuálním prováděném kroku.
Údaje následně upravil na formát podobný jako při vkládání, jen s identifikátorem „New“.
Př. 21 uživatel ve svém 87. kroku upravuje údaje v tabulce „Actor“ dle id 21087 na:
- First_name: FirstNameNew_U21_R87
- Last_name: LastNameNew_U21_R87
– Pro jeden každý projekt bylo provedeno 3000 těchto úprav (100 cyklů pro 30 uživatelů)
4. TEST– Smazání záznamu (DELETE)
Každý uživatel zkontroloval dostupnost svých záznamů dle generovaného ID a následně tento záznam smazal.
Př.: uživatel 3 v kroku 10 smazal záznam s ID 3010
– Pro jeden každý projekt bylo provedeno 3000 těchto smazání (100 cyklů pro 30 uživatelů)
5. TEST– Vše zároveň (ALL)
V tomto testu byly provedeny všechny dříve zmíněné kroky s tím rozdílem, že byly všechny prováděny najednou. To znamená, že každý uživatel si v jednom svém kroku nechal vypsat tabulku zákazníků, vytvořil nového herce s unikátním ID jménem a příjmením, tento záznam upravil a na závěr odstranil.
– Pro jeden každý projekt bylo zasláno 12000 požadavků (100 cyklů pro 30 uživatelů a 4 funkce).
Vlastní testování
Testované aplikace jsem vytvářel pomocí 14 nejznámějších frameworků, ve kterých jsem se snažil omezit některé doplňující vlastnosti, aby byly výsledné aplikace co nejvíce podobné. Na závěr jsme přidal i jednoduchou aplikaci napsanou v čistém PHP, která obsahovala pouze funkce určené k nejjednoduššímu zpracování daného požadavku.
Seznam použitých frameworků (abecedně)
- CakePHP 2.2.5, vydán 8. 1. 2013
- CodeIgniter 2.1.3, vydán 8. 10. 2012
- DooPHP 1.4.1, vydán 22. 2. 2011
- Jelix 1.5.0, vydán 20. 2. 2013
- Kohana 3.3.0, vydán 21. 10. 2012
- Laravel 3.2.13, vydán 11. 1. 2013
- Nette 2.0.8, vydán 19. 2. 2013
- Prado 3.2.1, vydán 19. 1. 2013
- Qcodo 0.4.22, vydán 15. 8. 2011
- Recess 0.20, vydán 7. 8. 2009
- Seagull 1.0.4, vydán 14. 1. 2013
- Symfony 2.2.0, vydán 24. 2. 2013
- Yii 1.1.13, vydán 30. 12. 2012
- Zend framework 2.1.4, vydán 13. 3. 2013
Co dál?
Během léta vám postupně předvedeme, jak si jednotlivé frameworky v testu vedly. Projdeme je v abecedním pořadí, každý týden ukážeme dva. Na konci pak vše přehledně shrneme.
Jaroslav Jakoubě
Student magisterského oboru Informační technologie na TUL. Jeho hlavní zálibou je programování webových aplikací nebo programů pro počítače a telefony. Oblíbené jazyky C#, Java, PHP. Velmi rád se učí novým věcem a nedokáže se od projektu odpoutat, dokud není dokončen. Pokud zrovna nepracuje vyráží na pěší výlety nebo na kolečkové brusle.
preco take stare verzie? je jul a vy pouzivate verzie zo zaciatku roka. take symfony je vo verzii 2.4, laravel dokonca zvysil major verziu na 4, zend takisto povysil a asi aj ostatne aktivne vyvijane.
ak by som si podla tohto testu mal teraz vyberat fw, tak ma zaujima vykon v aktualnej verzii, nie v pol roka starej
Místo toho aby jste autorovi poděkoval za to, že se do toho vůbec pustil, tak ho vyhejtujete? ( toto je prostě CZ-SK pohavaha, ničeho si nevážit ) Nejradši bych Vám dal pár facek, nikdo Vás to nenutí to číst a ještě lépe, místo „keců“ to udělejte vy!! Proberte se lidi, s takovým přístupem tu nebude nikdy nic.. Slušené by bylo se zeptat autra jestli může „přepsat“ testy na nové verze, nebo ještě lépe mu s tím pomoci.
ehm, vy mate problemy s temperamentom?
pytam sa ho preco zvolil take stare verzie, to je vsetko…
Celý test i jeho zpracování a vydání chvíli trvá. Nové verze budou vycházet neustále, dokud ale nedojde k nějakému dramatickému přepsání, bude srovnání stále dávat smysl.
Kritizovať „staré“ verzie frameworku je nezmysel (navyše nepravdivý – stabilná verzia Symfony je 2.3.1; na verzii 2.4 sa ešte len pracuje). Je nepodstatné v akej verzii sú dané frameworky, ale ich databázová vrstva/ORM. Napríklad v Symfony 2.1 je taká istá verzia Doctrine ako v aktuálne vyvýjanej verzii 2.4. A čo sa týka prístupu k databázovej vrstve/práce s ORM tak som v changelogu Symfony nenašiel žiadnu zmenu.
Jenom PHP patlal nasazuje úplně nové verze. Normální lidi používají ty prověřený se security updatama, tam půl roku není žádný stáří.
Tohle neni test PHP frameworku, ale ORM, ktere pouzivaji ty frameworky…
…resp. který je součástí oněch frameworků. Dobrá připomínka ač ne kritická, zamyslíme se, zda to nezdůraznit v názvu.
Což třeba u Nette, u kterého je databázová vrstva silně volitelná, může být dost zavádějící, ale nechme se překvapit, třeba autor zahrnul všechny tři varianty, které se běžně u Nette vyskytují Dibi, Doctrine a v poslední řadě Nette\Database.
Toto prave neplati jen o Nette, vyber ORM je v podstate kdekoli (v Symfony a Zendu urcite). Proc tedy neudelat test ORM a ne frameworku, ktere pouzivaji nejake ORM?
off-topic: je mi to celkem jedno, s PHP jsem se pred nejakym casem uz (mozna) nadobro rozvedli, ale mam rad zdrojak a chtel bych tu clanky, co davaji smysl.
By mě zajímalo kolik vývojářů vybírá framework primárně podle výkonu (klidně se ozvěte :) )? Domnívám se, že pokud nevytvářím zrovna Facebook, bude mi nejspíš výkonově stačit kterýkoliv z frameworků a budu řešit úplně jiné aspekty. Tím nechci schazovat tento článek, jen mě zaujalo ta věta o výběru.
Že by se nikdo nezajímal také o výkon? To se mi nechce věřit.
O výkon se vývojáři samozřejmě zajímají, ale často to není to hlavní kritérium. Protože kdybych se zajímal čistě jen o výkon nepoužiju ORM atd..
Však nikdo netvrdí, že je to hlavní kritérium, Jaroslav píše o skupině lidí (podmnožině), pro které je to hlavní kritérium.
Nejsem si jist, zda-li řešit rychlost ve frameworcích zrovna na úrovni databázových vrstev, vždyť každý může použít jakoukoliv vrstvu a dokonce je to i relativně běžná záležitost = někdo Doctrine, dibi, notORM, atd. A porovnávat rychlost těchto databázových vrstev také dost dobře nejde, zvláště když tedy ORM není jen nějaká PDO obálka na tahání dat.
Při testu rychlosti frameworků bych se spíše zaměřil právě na ty ostatní aspekty – rychlost a paměťovou náročnost renderování šablon, routování, v podstatě jednotlivých komponent daného cyklu requestu.
A jenom na okraj, tak v praxi u navštěvovanějších webů, kde je výkon podstatný, se stejně používá cachování, čili při výběru frameworku bych se mnohem více zaměřil na čistotu kódu, který mi umožní vytvářet a efektivitu využití – v podstatě kolik práce dokáže ulehčit – zjednodušeně o kolik se méně upíši, abych dosáhl cíle.
+1
Ved napriklad v Zende mozem do DB pristupovat:
1. priamo v controllery pristupovat do DB cez PDO
2. mozem pouzit Zend\Db\Sql
3. mozem pouzit TableGateway sposob pristupu
4. mozem si zacat vytvarat nejake biznis modely (Customer) s metodami ktore pristupuju do DB
5. pridam k tomu dalsiu vrstvu, biznis model Customer nepristupuje do DB priamo ale pouziva na to nejaku Resource classu
6. zacnem riesit ako budem svoj biznis model v controllery pouzivat takze pouzijem ServiceManager aby mi cez Dependency Injection automaticky loadoval moju classu.
..
…atd
Takze ak v jednom frameworku pouzijem metodu 1 a v dalsom metodu 6 aku relevanciu budu mat vysledky?
Ano, oceňuji, že si někdo dal tu práci a všechny ty frameworky porovnal. Ale je to už několikáté porovnání frameworků a všechny trpí tím samým. Neznalostmi toho, kdo je dělá.
Nechci autora podceňovat, ale nepředpokládám, že by byl nějak extra zdatný ve všech zmíněných frameworcích. Typicky je zdatný v jednom konkrétním a ten porovnává s ostatními (což je logicky biased – když v jednom používá best-way a v ostatních newbie-way). Tím pádem i kdyby byla samotná metodika testu v pořádku (tj. prostředí odpovídající reálnému nasazení a použití a ne syntetické testy „tisíckrát requestnu tuhle url bez cache“), tak stejně výsledek nebude vůbec vypovídající, vzhledem k výše zmíněnému.
Mimo to myslím, že není třeba znovu vymýšlet kolo. Poměrně respektované porovnání frameworků již existuje. Provnává dokonce mezi sebou různé jazyky a konfigurace! http://www.techempower.com/benchmarks/ Existuje tam určitá metodika, která se během jednotlivých kol ladí a autoři přijímají na githubu pullrequesty na nové frameworky a vylepšení/zrychlení u těch stávajících.
Dále tento typ benchmarkování neříká nic o tom, jak výkonná bude výsledná aplikace nebo kolik dá práce zaintegrovat do toho memcache, atp. Aby měl benchmark smysl, bylo by potřeba, aby někdo napsal třeba celý eshop v několika frameworcích s naprosto stejnou strukturou URL a výsledného HTML a pak napsal třeba seleniový test, který udělá 1000x nějaký komplexnější proces – třeba projití několika kategorií, objednávku, atp. Ale investovat tolik práce nedává vůbec žádný smysl, proto myslím, že maximum, které ještě smysl dává je ten techempower benchmark.
Chápu, že přimět někoho něco delšího napsat je problém, ale myslím, že zrovna tady měla redakce včas zasahnout a říct, že to nemá smysl ani začínat.
No vidíš. Mě to zajímá i přes všechny výtky i tak. A jsem rád, že redakce nezasáhla.
Díky za připomínky. Bude zajímavé srovnat pak výsledky s Techempower benchmarkem. Pochopil jsem, proč se někomu aktuální test nelíbí, takový už je podle mě osud většiny testů a v tomhle případě horko těžko něco změníme. Věřím, že i tak to někomu něco přinese.
Já jsem se právě Martine bál, že to přinese jen zmatení. Vypadne z toho nějaký hezký grafík „nejrychlejší framework“, ze ktrého bude všem všechno jasné, půjde hezky nasdílet jako ultimátní argument a celkově všem bude hned jasné, jak se to s tou rychlostí má a proč je který framework úplně na prd, protože tam jeden request trvá 3x déle než jinde :)
Zdroják by neměl přece být jen nějakým „prestižním agregátorem“ článků, které by jinak vyšli na nějakém zapomenutém blogu. To, že má nějakou redakci, nebo alespoň šéfredaktora by se mělo odrazit v tom, že zde publikované věci prochází nějakou revizí a mají určitou úroveň. Ten výše linkovaný web je TOP na „framework benchmark“ a dokonce i na „how to do framework benchmark“ – a já z toho vidím absenci jakékoli rešerše před napsáním…
Patriku, to jsem rád :) Ono to klidně zajímavé i být může, ale je to třeba brát v kontextu a ten by bez mého (a dalších) vyjádření chyběl. Já si ale myslím, že má smysl hledat spíš kvalitu (pokud potřebujeme srovnání rychlosti, udělejme jedno a to vylaďme), než kvantitu (srovnání CRUD operací v PHP frameworcích po 101.).
Velice si cením vašich příspěvků a omlouvám se že reaguji až tak pozdě. Při tvorbě aplikací jsem začínal vždy úplně od začátku a bez předchozích znalostí s daným frameworkem. Jsem si vědom, že takovéto testování není perfektní, ale neznám nikoho, kdo umi perfektně pracovat se 14ti frameworky.
Grafík z toho určitě vypadne, ale jak asi málo čtenářů pochopilo, tak nikomu jeho výsledky nenutím. Je pouze na každém jedinci, zda se mu bude tento test zdát užitečný nebo ne.
Bohužel jsem momentálně mimo stabilní připojení a nemohu okamžitě reagovat na všechny komentáře.
Preco sa autor rozhodol testovat vykonnost prave na CRUD operaciach?
Myslim, že nikdo nechce zpochybnit práci autora článku (o tom žádná), ale jde spíš o výsledky testu, u kterých už teď je jasné, že budou zavádějící a nicneříkající.
Představme si, že už je konec a máme výsledky. Na prvním místě se umístil fw X, na posledním fw Y. Rozdíl mezi X a Y je 500 ms. Znamená to tedy, že X je absolutně vždy nejrychlejší, zatímco Y je pomalá mrcha, kterou není radno vůbec používat.
U aplikací s větší zátěží, je volba fw důležitá, ale mnohem důležitější je spíš, jestli vůbec použít PHP. Pokud ano, tak to nakonec většinou skončí u toho, že se tak dlouho přepisují a upravují kritická místa, až z fw zbude jen část. Typicky mám vlastní jádro a z fw použiju jen části, komponenty..a to ne z jednoho, ale z vícero frameworků.
U fw mě spíš zájímá celkové soužití, efektivnost práce, dokumentace apod. Při výběru předpokládám, že všechny top fw jsou přiměřeně podobně rychlé, že žádný fw neklade při request toliko překážek, aby se očividně prodlužoval výstup. I kdyby fw sám o sobě odpověděl za 1 ms, tak pro SQL patlala je to nicneříkající číslo, protože výkon zabije nějakym „superdotazem“….
Celkově mi to přijde jako kdybychom postavili na start sporťáky od Mercedesu, BMW, Audi apod. a měřili, které je nejrychlejší. Výsledek testu by byl, že je to vlastně úplně jedno… (i když absolutní čísla by byla třeba 320, 319, 310 km/h atd…
Kdyby použil „superdotaz“, tak by to bylo ještě dobré. Patlal vám těch „superdotazů“ na jednu primitivní věc udělá víc :-)
zdravím,
ještě by mohlo být zajímavé otestovat http://phalconphp.com/ .. myslím, že je to zajímavá alternativa s velkou budoucností.
srovnání výkonu frameworků je skvělé a tady je podle mě jeden z nejlepších testů: http://www.techempower.com/benchmarks/