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_Ac­tion_Helper_Vi­ewRenderer.

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

Č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ář

Povinné

Povinné, skryté

Security Image Povinné
Opište text z obrázku

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


Kalendář

April 2024
M T W T F S S
« Jan    
1234567
891011121314
15161718192021
22232425262728
2930  

Poslední články

Locations of visitors to this page