EdeeShop opět rychlejší

Věčný koloběh v e-commerce

E-commerce aplikace jsou živoucí organismus – málokdy stačí zakázku vytvořit a provozovat bez dalších zásahů. E-shop tvoří u velké řady klientů důležitý prodejní kanál, a proto mu věnují náležitou pozornost. Během roku se v aplikaci průběžně něco mění, přidává, redesignuje, upravuje a dost často i týmem, který tvoří jiní vývojáři než ti, kteří původní řešení vytvořili.

Druhým důležitým faktorem je životní cyklus dat, která jsou často přebírána z backend ERP systémů buď přímým napojením (což je v současnosti nejběžnější forma integrace) či pomocí pravidelných importů. Pokud vývojový tým předává do produkce e-commerce aplikaci otestovanou na 3GB databázi, může se klidně stát, že za rok či dva je databáze násobně velká – ať už z důvodu zkvalitňování informací o produktech, rozšířením sortimentu, přidávání lokalizací, B2B prodejního kanálu, nových e-shopů sesterských firem či dalších faktorů, které jsou běžnou součástí obchodních aktivit zákazníka.

Oba výše zmíněné faktory vytvářejí tlak na výkonnost aplikace, která se sice dá řešit posílením hardware, ale z dlouhodobé perspektivy je výhodnější investovat do optimalizace aplikace jako takové. Samozřejmě existuje bod zlomu, kdy je další optimalizace aplikace dražší než nákup dodatečného hardware.

Díky sdílenému jádru naší platformy Edee.one se investice do zrychlení jádra projeví u desítek klientů, a proto je zde optimalizace nákladově velmi efektivní volbou.

Příběh klienta s oblečením…

Výše uvedený příběh si můžeme popsat na našem klientovi Fjällraven. Když se spouštěl jeho první e-shop, čítala databáze produktů 10 tisíc položek. Už v té době nás překvapilo, kolik variant může jeden produkt mít. Nabídka klienta je s ohledem na dostupné barvy a velikosti veliká – jeho největší „master“ produkty zastřešují až 330 variant reálných produktů. To, co nás překvapilo před dvěma lety, je však dnes již několikrát překonané - pro jiného klienta, který dodává luxusní zboží spravujeme „master“ produkty s téměř 2 tisíci variantami v každém z nich.

S postupem času se jeho řešení rozšířilo na nabídků 30 tisíc položek, 7 jazykových lokalizací a 4 prodejní e-shopy s integrací na MALL tržiště – reálně tedy řešení pracuje v souhrnu s 271 tisíci záznamy o produktech. Postupně také narůstá návštěvnost, obrat řešení a počet automatických úloh provádějících integrace na backend a externí systémy. Klient také značně využívá produktových balíčků, díky kterým je možné sady produktů nakupovat s citelnými slevami. Vazby mezi produkty tedy také násobně narostly.

Plíživě se snižovala odezva webu pro návštěvníka až ke 3 sekundám na nejnáročnějších stránkách, což bylo za hranicí únosnosti. A proto se do backlogu našeho týmu dostal úkol k provedení optimalizací, které povedou ke zlepšení odezvy nakupujícím.

…si vyžádal důkladnou revizi…

V rámci vývoje verze 8.16 jsme provedli důkladný audit všech operací, které frontend při vykreslování nejnáročnějších stránek provádí. Ten odhalil celou řadu neefektivit, které bylo možno odstranit:

• díky možnosti vybrat si z některých variant už v přehledu produktů docházelo k tomu, že pro zobrazení stránky s mnoha master produkty docházelo k načítání informací o všech jejich variantách (byť v základním rozsahu, který obsahoval jen minimum dat). To mělo za následek, že stránka s 24 zobrazenými produkty si reálně mohla načítat data o více než tisíci existujících variantách produktu z databáze. Tato neefektivita byla odstraněna chytřejším způsobem předpublikace variantních informací
• nemalé množství dat se načítalo zbytečně – návrh API byl velmi vstřícný k vývojářům, kteří měli řadu dat ihned po ruce a stačilo je jen vykreslit. Díky obecnosti API pro různé klienty však tato data nebyla využívána všude a každý klient potřeboval něco trochu jiného. Naše API tedy prošlo „odtučňovací kůrou“ a mnohem více dat se nyní načítá „líně“ (lazy) pomocí techniky AOP.
• AOP a líné načítání dat bylo sice již implementováno v předchozích verzích, ale objevili jsme citelné nedostatky, které vedly při určité kombinaci zapnutých funkcionalit k opakované inicializaci stejných dat. Konkrétně kombinace master produktů s velkým množstvím variant v kombinaci se sadou jiných master produktů v produktovém balíčku umožňovala rozsáhlé optimalizace
• další revizí prošel i formát dat ukládaných v databázi – díky průběžným aktualizacím řešení u všech našich klientů bylo možno opustit zpětně kompatibilní formáty pro uložení publikovaných dat, které byly navrženy před několika lety v prvních verzích řešení, a data citelně zjednodušit a zmenšit
• byly doplněny další cache na místa, která byla často využívaná a u nichž je cachování z pohledu znovupoužitelnosti efektivní. V souvislosti s tím došlo i k rozšíření možností cílené invalidace cache, která umožňuje daná místa lépe vyprázdnit, jakmile se zjistí, že jejich data zastarala
• v rámci stránky vyžadovalo načtení správné varianty jakéhokoliv produktového obrázku jeden (byť rychlý) dotaz do relační databáze – tato operace byla v nové verzi zcela odstraněna

…a je příběhem se šťastným koncem

A to je nejen pro něj, ale i pro všechny další naše klienty. Konkrétně u Fjällraven jsme dosáhli zrychlení z 2.4 sekundy na nynějších 800 ms v 95 % požadavků na plné načtení HTML dokumentu stránky. Na jiném e-shopu stejného klienta Levi.sk dokonce z 3.5 sekundy na nynějších 700 ms v 95 % požadavků. U klientů s jednoduššími daty dosahujeme odezvy 350 ms i méně.

Zlepšování výkonu řešíme neustále a příští rok bychom chtěli nabídnout zcela novou generaci frontendu našich e-shopových řešení, která bude využívat i nový vyhledávací stroj. Od obého si slibujeme řádové zrychlení odezev i těch nejnáročnějších e-shopů, což umožní snížit provozní náklady našim klientům a zpříjemnit uživatelskou zkušenost jejich zákazníků při nákupech.