V tomto článku si představíme způsob, kterým můžeme zvýšit výkon a snížit nároky webové aplikace využívající Doctrine 2 s minimálním zásahem do aplikace.
Testujete (či se chystáte testovat) přístupnost webových stránek s odečítači obrazovky a zajímá vás, s jakými konkrétními kombinacemi odečítačů obrazovky a webových prohlížečů dává smysl takové testy dělat?
Poznámky z knihy 97 Things Every Software Architect Should Know.
Jen v loňském roce si lidé stáhli 194 miliard mobilních aplikací. Centrem jejich vývoje se 31. května stane už po osmé Praha, to díky největší konferenci pro mobilní nadšence ve střední Evropě – mDevCamp.
Očekávání vs. Realita
Ahoj Tome, díky za přehledný článek. Ten graf se mi moc líbí! :)
Mám 2 otázky do praxe:
1) Jak moc dlouho ti trvalo to všechno nasát a zjistit, abys to mohl použít v praxi? Zajímá mě hodinová zátěž úkolu „přidat Doctrine 2nd level cache“ pro někoho, kdo zná Doctrine, ale čte o 2nd level cache poprvé.
2) Jak velké je zrychlení např. na přehledu produktů, relativně i absolutně a při jakém počtu produktů (a další elementů, které tam jsou a mají roli a teď mě nenapadli).
Propaguji 2nd level cache ve firmách, kde Doctrine používají, ale chybí mi reálná čísla k přesvědčení :)
Re: Očekávání vs. Realita
Ahoj Tome, titulek „Očekávání vs. Realita“ je skvělý! :)
Ad 1) Cesta od objevení SLC k jejímu použití je kratší než by se mohlo zdát. Když se ti nechce číst dokumentace, tak to jsou vlastně pouze dva kroky:
setSecondLevelCacheEnabled()a poté stačí předat cache továrna přessetCacheFactory()viz. https://www.doctrine-project.org/projects/doctrine-orm/en/2.6/reference/second-level-cache.html#enable-second-level-cache.@ORM\Cachedo entity, která se má odkládat do SLC.Jak vidíš, tak je to práce na 5-10 minut? :) Samozřejmě, že čím více začneš využívat SLC (i pro kolekce), tak se už dokumentaci nevyhneš. Když pak narazíš na nějaký edgecase, tak musíš projít i samotné zdrojové kódy a pak toho načerpáš daleko více. Stačí se nebát a nahlédnout pod pokličku. ;) Z mého pohledu je zátěž na základní implementaci skoro nulová.
Ad 2) Zrychlení aplikace je velmi relativní. SLC totiž není zázračná skřínka, kterou zapneš a ona ti zrychlí aplikaci o 50%. Je to nástroj pro snížení počtu dotazů do databáze. Pokud máš tedy navštěvovanou aplikaci (řádově stovky lidí online) a podaří se ti ušetřit jeden sql dotaz, který se provede každému zákazníkovi na každé stránce (např. zjištění lokalizace podle domény), tak díky tomu ušetříš statisíce provedených SQL dotazů za den. Cílem je tedy snížit zatížení databáze.
Ze zkušenosti ti mohu říci, že když dáš do SLC všechny entity v aplikaci, tak do databáze nepůjde opravdu žádný dotaz. Je potřeba, ale myslet na to, že data musí být z nějakého zdroje načteny. Pokud se ti předtím provádělo třeba 100 requestů do DB, tak se SLC se ti bude provádět 100 requestů do cache (např. Redisu). Když si toto uvědomíš, tak zjistíš, že před využitím SLC je dobré se zaměřit na snížení počtu dotazů do databáze (např. přes manuální hydrataci kolekcí viz. https://ocramius.github.io/blog/doctrine-orm-optimization-hydration/). Když se ti povede snížit počet dotazů do databáze a pak nasadíš SLC, tak je to win-win situace. :)
O tom jaké jsou možnosti snížení počtu dotazů do DB bych mohl připravit navazující článek. Každopádně to také probíráme na demo aplikaci na školení. ;)
Přesná čísla o tom, jak pomohla SLC u nás na lekarna.cz ti bohužel říci nemůžu, protože si je už nepamatuju. :D Novou verzi lékárny jsme spouštěli před rokem a tyto optimalizace se dělali ještě před spuštěním. Co si, ale pamatuji tak to bylo řádově desítky procent ušetřených dotazů. Ne všechny entity můžeš na e-shopu držet v cache.
Abych ti dal nějaká skutečná čísla, tak ti mohu říci, že na jednom připravovaném projektu se počet dotazů vyvíjel takto:
Suma sumárum je to snížení počtu dotazů do databáze na jeden request o ~91% a to je pěkné číslo.
Snad jsem ti vše srozumitelně vysvětlil. :)
Re: Očekávání vs. Realita
Za redakci dodávám, že navazující článek rozhodně vítáme a oceníme. 👍