Patrik Votoček

weBlog



ORM & Nette Framework v číslech

Zdálo se mi, že je Doctrine 2 je extrémně pomalá a proto jsem zvažoval, že ji opustím. Ale abych to měl podloženo, pustil jsem se do testování. Udělal jsem si jednoduchou aplikaci v Nette, která dané ORM pořádně otestuje. 

Postup

Vytvořil jsem si testovací databázi (s 50000 záznamy) pomocí http://php7.org/tools/adresy/. Databáze obsahovala dvě tabulky Peoples a Cities, kde Peoples je k Citites svázáno 1:N. Testy jsem rozdělil do 4 částí:

  • SELECT 1000 řádků + asociace
  • INSERT 50 řádků
  • SELECT → UPDATE 50 řádků
  • SELECT → DELETE 50 řádků

Každou část jsem opakoval 10× a před změnou ORM jsem uvedl databázi do „původního“ stavu. Vytvořil jsem pevně dané rozhraní a prototypy modelových objektů, aby si byly jednotlivé implementace co nejblíže.

Srovnání

Čas (ms)

ORM Select Insert Update Delete
dibi 2627.6 1872.98 2139.15 1828.69
Ormion 4259.76 2329.13 2362.64 1900.73
ActiveMapper 2984.82 2424.43 2686.64 2169.64
Doctrine 2 1141.73 2662.93 2759.14 2071.21
Doctrine 2 Cache 1184.45 2453.44 2377.53 1834.51
Doctrine 2 Query Bulder 2059.5 2509.4 2895.39 2124.33
Grafické znázornění předchozí tabulky

Paměť (kB)

ORM Select Insert Update Delete
dibi 7927.17 6246.37 6252.02 6192.02
Ormion 11825.67 6886.85 6889.32 6704.57
ActiveMapper 10089.7 7350.68 7547.15 2169.64
Doctrine 2 11106.07 8755.15 8796.66 8704.21
Doctrine 2 Cache 11116.33 8760.32 8803.21 8709.92
Doctrine 2 Query Bulder 11803.94 9425.11 9312.05 9215.72
Grafické znázornění předchozí tabulky

Závěrem

Takový výsledek jsem doopravdy nečekal. A jistě ani spousta z vás. Kódy benchmarku jsou na GitHubu . Pár informací o testovacím prostředí:

  • PHP 5.3.3 NTS VC9
  • IIS 7.5
  • Windows 7 x64
  • MySQL 5.5.3-m3-community
  • Nette Framework 1.0-dev (revision a8c51dd released on 2010–07–23)
  • 3GB DDR2 RAM
  • Core 2 Duo T5550

10 komentářů


Honza Marek

nový

  1. Ormion koukám výkonově až tak neválí.
  2. Doctrine 2 Cache máš asi stejně výkonnou jako bez Cache, asi by to chtělo najít nějaký složitější příklady do testu. Třeba by to pomohlo i Ormionu, když nemusí překládat DQL.
Honza Marek avatar

Patrik Votoček

nový

Doplnil jsem Query Bulder. Ten je totiž ještě náročnější než DQL (protože QB → DQL → SQL).

Patrik Votoček avatar

srigi

nový

Skoda, ze si netestoval aj NotORM (pre SELECTy). Inak na slideshare som videl nejake slides o Doctrine 2 a tvrdilo sa tam, ze vdaka „inteligencii“ EntityManager moze byt Doctrine 2 rychlejsia ako raw PHP.

srigi avatar

Patrik Votoček

nový

Dalo by se říct že jsem NotORM netestoval schválně. Právě protože to není ORM. Testoval jsem ORM + dibi.

Ad Doctrine 2 rychlejší než raw PHP test byl záměrně psán celkem hloupě aby se projevila síla jednotlivých řešení. Věřím že po optimalizaci by byla Doctrine 2 ještě rychlejší. (Možná někdy později udělám optimalizovaný tes­t)

Patrik Votoček avatar

Václav Novotný

nový

Na jakém databázovém serveru jsi to konkrétně zkoušel? MySQL 5.něco?

Chtělo by to ještě porovnat počty dotazů, které na databázi šly, protože se budou v jednotlivých řešení různit.

Václav Novotný avatar

Jakub Vrána

nový

Netestovat NotORM proto, že nejde o ORM mi přijde nešťastné, protože jde o knihovnu, která může být použita právě místo ORM.

Díky publikaci zdrojových kódů testu jsem ale verzi pro NotORM mohl dopsat. Výsledky dopadly v zásadě podle mého očekávání – NotORM je nejrychlejší: http://php.vrana.cz/…2-i-dibi.php

Bylo by fajn, kdybys verzi pro NotORM spustil na své konfiguraci, aby se čísla dala porovnat. Publikoval jsem ji také na GitHubu.

Jakub Vrána avatar

Jan Tichý

nový

„Takový výsledek jsem doopravdy nečekal.“ – Jakože dobrý, nebo jakože špatný pro Doctrine 2? Mne to taky dost překvapilo, tak se chci jenom ujistit, že mě to nepřekvapilo v opačném gardu, než Tebe.

Jan Tichý avatar

Patrik Votoček

nový

@Václav: je to tam napsané 5.5.3-m3 @Jakub: v dalším článku jsem jej použil @Jan: Jako že jsem mile překvapen. (vzhledem k charakteru testu jsem čekal řádově horší výsledek)

Patrik Votoček avatar

David Grudl

nový

Škoda, že jsi pro test použil zápis přes DibiFluent, naměřené časy by razantně poklesly. Fluent jsem pro výkon neoptimalizoval, jde spíš o hříčku. Kód benchmarku bez fluentu je tady http://github.com/…rk/tree/dibi

David Grudl avatar

Patrik Votoček

nový

Cílem testu bylo se co nejvíce vyhnout SQLku. Proto jsem použil fluent. Ale je fakt že Fluent je vpodstatě jiná syntax SQLka. Navíc dibi bylo v testu jenom pro srovnání.

Patrik Votoček avatar

Přidej komentář



cenzuruje váš poskytovatel připojení?

Kategorie

Čtu

Kamarádi