Zend Framework - benchmark pro PHP a Smarty view vrstvu
11. September 2007
Jedním z důležitých kriterií při tvorbě webových stránek je rychlost jejich generování. V systémech jako je Java nebo Asp.Net je nám hej – náročné operace (start ORM nástroje atd) si odbydeme při startu aplikace a při obsluhování požadavků se využívá již vytvořených objektů.
Ve skriptovacích jazycích – mám na mysli konkrétně PHP – jsme na tom jinak. Při zpracování požadavku se musí celá naše aplikace postavit a po jejím skončení se zase sbourá. V PHP si nemůžeme dovolit startovat při každém požadavku náročné části systému.
Když jsem před léty vplul so světa Javy začal jsem přenášet některá její řešení do PHP. Například jsem ze Spring Frameworku přenesl do PHP část architektury – servisní třídy, DAO objekty, doménové objekty, proxy objekty a také jsem po vzoru Hibernate naimplementoval vlastní ORM systém v PHP, kterému říkáme eVent. Bohužel, se tato cesta ukázala jako né zcela správná – výsledný webový projekt byl nadmíru robusní, ale měl žalostně špatný výkon. Doba pro generování stránky se pohybovala v řádu desetin sekundy. Pomalé generování stránky může mít obecně různé důvody:
- špatný návrh webu (chyba programátora)
- malý výkonu webového serveru
- velké množství zobrazovaných dat (např. stovky nebo tisíce zobrazovaných objektů)
Tak či onak všech výše uvedených věcí je dobré se vyvarovat.
Po provedení odtučňovací kůry a nasazení nové verze Zend Frameworku jsme se dostali na časy v řádu desítek milisekund (a v drtivé většině se to pohybuje mezi 10 a 20 milisekundami).
Benchmark pro ZF s PHP nebo Smarty jako view vrstvy + Plain PHP
Na několika místech na webu (Výkon: CodeIgniter, Smarty a PHP, Template Benchmarks) jsem se dočetl o žalostném výkonu templacovacího frameworku Smarty. Přiznám se, že i já jsem byl přesvědčen, že to je jedno z úzkých hrdel některých našich webů. A proto jsem se rozhodl provést malý test, abych zjistil jak to skutečně je.
Parametry benchmarku
Benchmark jsem prováděl na notebooku Acer Aspire 5672, Dual Core T2300 1,66 GHz, 2 GB RAM. Testoval jsem stránku, na které přistupuji do databáze a z vypisuji na obrazovku data o 100 uživatelích. Varianty testu:
- Zend Framework + PHP
- Byl použit ZF 1.0.1. Pro přístup do databáze jsem použil Zend_Db. Jako view vrstva byla použita klasická PHP stránka (defaultní implementace v ZF).
- Zend Framework + Smarty
- Byl použit ZF 1.0.1 a verze Smarty 2.6.17. Pro přístup
k databázi jse opět použil
Zend_Db
. - Plain PHP
- Pro zajímavost jsem do testu zařadil i plain PHP stránku – myslím tím tedy jediný PHP souboru, který získává data z databáze a rovnou je zobrazuje.
Jako testovací nástroje jsem použil jMeter. Testplan se skládá z dotazu je tuto jedinou stránku. Ramp-up period byla nastavena na 1 sekundu (doba, ze kterou dojde k vytvoření zadané počtu požadavků). Měnil jsem počet uživatelů a počet cyklů v rozsahu od 1 do 50 resp. od 10 do 50.
Pokud si chcete benchmark vyzkoušet na svém stroji zde je ke stažení – zf-test.zip (zip, 2,4 MB). View vrstvy se v projektu nastavují pouhým přidáním parametru engine do URL:
- engine=plain-php pro Plain PHP
- engine=zf-smarty pro ZF a Smarty
- bez parametru engine pro ZF + PHP
Archiv obsahuje ZF projekt a také soubor php-benchmark.jmx pro jMeter.
Výsledky benchmarku
V následující tabulce jsou výsledky mého testu. Údaje jsou uvedeny v milisekundách.
Počet uživatelů | Počet cyklů | Požadavků celkem | Plain PHP | ZF + PHP | ZF + Smarty |
---|---|---|---|---|---|
1 | 10 | 10 | 11 | 132 | 125 |
5 | 10 | 50 | 11 | 315 | 322 |
10 | 10 | 100 | 13 | 676 | 722 |
15 | 10 | 150 | 47 | 1071 | 1117 |
20 | 10 | 200 | 85 | 1389 | 1415 |
20 | 20 | 400 | 123 | 1422 | 1513 |
30 | 20 | 600 | 249 | 2427 | 2526 |
50 | 50 | 2500 | 426 | 4215 | 4395 |
Výsledky benchmarku – ZF s použitím PHP nebo Smarty jako view vrstvy + Plain PHP
Závěr
Na výsledcích testu mě zarazilo, že ZF + Smarty je na tom výkonnostně téměř stejně jako varianta ZF + PHP. Vysvětluji si to tak, že předmětem testu byla stránky, které prováděla pouze jednoduché iterování přes kolekci. Nebyly použité žádné speciální Smartí značky nebo funkce. Dalším důvodem může být, že použití PHP jako view vrstvy pro ZF má také svoji režii – vytváří se například Zend_Controller_Action_Helper_ViewRenderer.
Na výsledcích je dále vidět režie samotného Zend Frameworku – samostatná PHP stránka jej výkonnostně zcela válcuje. Přesto myslím, že pro aplikace, které nejsou extrémně zatížené, výkon ZF vyhovuje. Ještě zde máme trumfy v rukávě – použití kešování nebo různých akcelerátorů.
Odkazy
- FastTemplates – šablony v PHP
- TemplatePower
- FastTemplate 1.1.0 Homepage
- The ionCube PHP Accelerator
- Template Benchmarks
- SMARTY – šablonovací systém pro PHP
- HTML_Template_IT
- ModeliXe
Článek patří do kategorie: Zend Framework
12 Komentářů Přidat komentář
1. dafodil | 11. September 2007 v 23.31
Parada, tak na podobne srovnani jsem byl zvedav jiz delsi dobu, ale nemel jsem odvahu do toho prastit. Na druhou stranu byl rozdil mezi plain php a pouzitim ZF zrejmy.
2. kareem | 12. September 2007 v 8.58
Ta podobnost času ZF + PHP a ZF + Smarty by se podle mě dala vysvětlit tím, že se smarty šablony při prvním requestu zkompilují do PHP kódu a pak už se samotná šablona vůbec nemusí parsovat.
3. Vojtěch Vít | 12. September 2007 v 15.12
Můžete prosím překontrolovat URL odkazu na ZIP archiv benchmarku? Pod tím odkazem mi to vrací jen nějakou chybovou hlášku…
Jinak neuvažoval jste někdy o použití kombinace technologií XML + XSL namísto Smarty? Jaký je váš názor na tento postup?
4. Vlasta | 12. September 2007 v 15.19
[3]Omlouvám se za nedopatření. Soubor je již na svém místě.
Kombinace XML + XSL je myslím pro svět PHP použitelná je ve velmi omezených případech – instranety, interoperabilita s jinými systému. Podle dosavadních zkušeností je to zatraceně pomalé.
Kombinace XML + XSL je dobrá pro statické weby – vytvářel jsem několik statických webá tak, že jsem si dal data do XML souborů a pak to v batchi hromadně prohnal přes XSL transformátor.
5. optik | 19. September 2007 v 16.38
to se asi dalo cekat, ted by to chtelo zjistit, co to brzdi, podle toho, co jsem tak cetl je to hlavne IO a otvirani tuny
souboru pri require/include to se da sice trochu optimalizovat pres opcode cache (APC apod), ale podminene require
a __autoload() (coz se hojne pouziva prave u Front Controller frameworku) pry pouziti opcode cache dost degraduji. Asi z toho neni moc vychodisko, mozna casem nekdo vymysli neco, co bude umet nejak efektivne cachovat opcode trid/objektu misto souboru.
6. Dundee | 14. December 2007 v 11.54
Alokaci paměti jsi náhodou netestoval?
7. Vlasta | 14. December 2007 v 12.08
[6] Bohuzel netestoval.
8. Ondra | 18. December 2007 v 11.38
Mohl bych se zeptat co přesně znamená v testu ten počet cyklů?
9. Vlasta | 18. December 2007 v 12.13
[8] Jedním z parametrů cyklu je počet uživatelů a dalším počet cyklů. JMeter pracuje tak, ze na testovanou URL pošle pro za každého uživatele požadovaný počet dotazů (cyklů). Náběh jednotlivých uživatelů (požadavky se netvoří současně) se řídí tzv. rampup timem – časovým intervalem mezi požadavky od dvou uživatelů.
10. Ondra | 30. April 2008 v 12.47
Promiň že se ještě ptám, ale není mi to moc jasné:
Je to tak že během jedné vteřiny se vygeneruje (pocet_uzivatelu * pocet_cyklu) požadavků? A nebo během první vteřiny generuje pocet_cyklu požadavků jeden uživatel a s každou další vteřinou o jednoho víc? Cyklus je tedy počet požadavků od jednoho uživatele za jednu vteřinu? Nebo je to úplně jinak?
Předem moc dík za odpovědi, moc by mi to pomohlo
Ondra
11. Vlasta | 30. April 2008 v 16.58
[10] Je to tak, že během 1 s (ramp-up time) se vygeneruje POCET_UZIVATELU požadavků. A to celé se zopakuje celkem POCET_CYKLU krat.
12. Ondra | 5. May 2008 v 9.28
Díky moc, teď už je mi to jasný
Přidat komentář
Povolené HTML značky:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>
Odkazovat na tento článek | Přihlásit se k odběru těchto komentářů přes RSS Feed