Performance tunning — jak na to?

Petr Jůza
Dec 2, 2020 · 7 min read

S laděním performance (performance tunning, performance optimization) se potkal asi každý v průběhu své IT pracovní činnosti, někdy nevědomě, kdy se jednalo o drobná vylepšení v kódu vedoucí ke zrychlení konkrétní funkčnosti, jindy vědomě, kdy se na zlepšení performance vytvořil samostatný projekt.

Stejně jako jiné technické činnosti, tak i performance tunning lze dělat více dobře nebo více špatně. Já se v tomto článku pokusím shrnout mé zkušenosti z této oblasti, poukázat na nejčastější chyby nebo naopak říci co může fungovat. Ladění performance se v nahodilých intervalech vlastně věnuji celou mojí pracovní kariéru, dokonce určitý krátký čas jsem se tomuto tématu věnoval výhradně.

Image for post
Image for post

Předpoklady pro úspěšný tunning

Hlavní předpoklad je v zásadě pouze jeden — znát přesně požadavky na systém, znát cílovou metu.

Ladění performance lze označit za systematickou činnost, při které postupně směřujeme k cílovým požadavkům, které pokud nebudou zcela exaktně definované, tak nemůžeme vědět, kam vlastně směřujeme. Jednak si často musíme umět vybrat, co je pro nás důležitější, jaké performance parametry mají přednost — chceme systém s co nejnižší latencí nebo naopak s co největší prostupností (throughput)? Je pro nás nezbytností datová konzistence (consistency) a trvanlivost (durability) nebo můžeme obětovat tyto vlastnosti pro dostupnost (availability)? Nemohu chtít vždy všechno (typicky volba dvou ze tří kritérií v CAP teorému) a musím co nejpřesněji znát co je mojí prioritou, protože mě to pak výrazně usnadní v rozhodováních, které budu v průběhu performance ladění muset dělat.

Cílové parametry je nutné mít zcela přesně definované, nic ve smyslu jako “o něco rychlejší” nebo “stejně rychlé jako tato funkčnost” neobstojí. Jak uvidíte dále, vše musí být zcela jasně měřitelné, protože co se nedá měřit, to nelze vylepšovat (nebo aspoň nikoliv efektivně). Tedy správná definice je např. “po dobu 30 minut je očekávaná prostupnost 1.000 requestů/s, maximální latence 500ms”.

Zkušenost je taková, že se tyto parametry často definují až v momentě, kdy je nutné řešit nějaký problém, přitom před implementací jakékoliv nové funkčnosti by se měli definovat nejen funkční požadavky, ale i ty nefunkční a tím nastavit akceptační kritéria nejen z pohledu uživatele, ale také z pohledu provozování. Neumluvě o tom, že podle nefunkčních požadavků se dělá sizing HW.

Aby člověk mohl efektivně řešit technické otázky, musí dle mého názoru znát i businessový kontext, protože až potom bude schopen vše řešit s dostatečným nadhledem. Těžko se ladí performance, když člověk neví jaká data tam putují, co je jejich obsahem, jaká specifika mají apod. Často to jsou právě různé businessově okrajové požadavky, na které se během vývoje nebo testování trochu pozapomělo a nyní se to na produkci vyboulilo.

Měřit, měřit, měřit …

Nejednou si vzpomenu na mého vysokoškolského učitele, který nám opakovaně vysvětloval, že Teorie řízení je exaktní technický obor a vše lze naprosto přesně změřit a zaznamenat. A díky tomu lze systematickým přístupem věci zlepšovat, ale vždy za podmínky, že přesně vím kde jsem, tedy umím měřit, opakovaně měřit, opakovaně měřit za stejných podmínek.

To se celkem jednoduše řekne, ale zajistit konzistentní a stabilní prostředí není vždy úplně jednoduché, stačí aby těch systémů nebo komponent po cestě bylo více a hned se náročnost tohoto úkolu zvyšuje. Umět měřit co přesně potřebuji také není tak jednoduché jak se na první pohled zdá, protože takové metriky budu muset třeba doprogramovat, budu muset zavést systém pro sběr takových dat, abych je uměl následně analyzovat a dávat do souvislostí. Zde hrají nenahraditelnou roli systémy jako Elasticsearch, Kibana, Grafana, Prometheus, ZipKin apod.

Organizace a tým

Máme referenční prostředí, víme co je naším cílem a umíme měřit aktuální stav — můžeme se tedy do toho pustit … Možná se ještě na chvíli zastavme u organizace celé aktivity, jaké role vlastně potřebujeme k efektivnímu řešení.

Hlavním hybatelem je vetšinou člověk s rolí solution nebo aplikačního architekta (v případě, že řešíme performance v rámci jedné aplikace resp. komponenty), jehož hlavním cílem je zacílit, tedy ukázat na možná slabá místa, ukázat na konkrétní komponenty k dalšímu podrobnějšímu řešení. Tento, hlavní, člověk je zodpovědný za správné směřování celé aktivity, koordinuje dílčí akce a udržuje informaci, kde se právě tým nachází a co bude nutné dále řešit. U něj se potkávají všechny důležité informace, on je primárně vyhodnocuje. Tento člověk je rolí převážně architekt, částečně organizátor a čím více znalec technologií jednotlivých komponent, tím určitě lépe.

Pokud performance ladíme přes více komponent, tak se neobejdeme bez detailních znalostí pro každou takovou komponentu, pokud na ní ukážeme, že je potenciálně problematická. Ať už se jedná o Java nebo .Net aplikaci nebo databázi nebo cache nebo různé infrastrukturní komponenty, vždy bude potřeba někdo, kdo konkrétní pochybnost prozkoumá a vysvětlí, později případně opraví. Toto může být vývojář, externí expert za danou technologii, prostě kdokoliv, kdo dané komponentě opravdu rozumí.

A samozřejmě potřebujeme mít k dispozici testing (nejčastěji toto řeší právě on, může být ale i tým provozu nebo samotný vývojový tým, záleží co se a kde se přesně ladí), který bude schopný opakovaně provádět performance testy a měřit jejich výsledek. Je potřeba umět testovat jak jednotlivé komponenty izolovaně, tak i celek dohromady — toto platí zejména pro různé komunikační komponenty (např. Apache Kafka), kdy nejednou jsem byl svědkem toho, že jednotlivé komponenty izolovaně fungovali zcela bez problémů, nicméně dohromady již nikoliv.

Nejčastější chyby

V poslední části bych uvedl několik častých chyb, na které jsem měl možnost narazit

  • je potřeba předcházet špatným rozhodnutím, bez dobrého návrhu architektury to nepůjde. Přijde mě, že se často více řeší lokální performance, aby daný algoritmus fungoval co nejlépe, nicméně je to celkový design, který rozhoduje o tom, že to celé bude fungovat jak má, že to bude performovat. Problémy na úrovni algoritmu se fixují celkem jednoduše, iterativním způsobem se to většinou dají vyřešit, ale chyby v návrhu celého řešení se už jednoduše neodstraní. A jak určitě sami víte, tak opravy chyb v návrhu jsou ty nejdražší. Je proto důležité dělat i důkladné review architektury, nejen kódu.

Závěr

Zažil jsem ladění peformance, které trvalo měsíce, ale i akce, kdy jsme během prvních pokusů byli schopni odhalit příčinu a během druhého dne jsme ji opravili a vše fungovalo jak mělo. Z mých zkušeností je ale blíže k realitě první scénář, kdy je nutné nastavit systematický přístup k řešení a krok po kroku pokračovat směrem do cíle. Někdy to může trvat dny, jindy týdny nebo měsíce, ale pokud vše máme správně nastavené a postupujeme systematicky, pak jdeme správným směrem. Bohužel zkratky málokdy fungují, a proto je potřeba být trpělivý a vytrvalý, vědět v každém okamžiku kde přesně jsem, proč to dělám a jaké budou další kroky. K tomu potřebuji mít připravený monitoring s vhodnými metrikami.

PS: pár konkrétních fuckupů na konec

  • Spring SpEL obsahoval nevhodně zapsaný výraz, který se nemohl optimalizovat a navíc se vždy řešil pomocí rekurze.

OpenWise Tech blog

Stories from our development

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store