Zaregistrovali jsme nejen v poslední době stesky uživatelů informačního systému operačního řízení nad tím, že „nám nefunguje systém, protože jim nepřijde navigace do auta„. Tyto stesky jsou v případě zařízení jednoho z poskytovatelů navigací namístě – v řadě případů příkazy k jízdě do vozidel opravdu nepřijdou.
Ale co je tím skutečným důvodem, proč „s tím nemůžeme něco udělat“ a jak to vlastně celé funguje, to už je složitější vysvětlení.
Jádrem celého systému je kromě databáze také aplikační server. Aplikační server si můžeme představit jako úřad se spoustou úředníků. Tito úředníci jsou sdružování do odborů, které realizují obsluhu činností podobného typu.
Nejznámější odbor je zodpovědný za styk s veřejností. Na každé směně je v něm připraveno na 200 úředníků, kteří čekají na požadavky, které jim pokládají uživatelské aplikace – Spojaři, IKISové a jim podobní. Aby byla veřejnost spokojena, tak se každý úředník snaží požadavek vyřídit co nejrychleji. Proto sám zařídí jen to, co má být vráceno v odpovědi na požadavek. Všechnu ostatní práci s požadavkem spojenou přenechává druhému velkému odboru – odboru pro zpracování vnitřních událostí. Tam pracuje téměř 100 dalších úředníků.
Takto to vypadalo na začátku
Předvedeme si to na příkladu – obsluha Spojaře posílá techniku k zásahu. Úředník z odboru pro styk s veřejností požadavek přijme a zkontroluje, zda je možné tuto techniku k události odeslat. Pokud ano, tak změní její stav na „Výjezd“, vytvoří o tom vnitřní událost (zprávu pro příslušný odbor) a vrátí zpět Spojaři, že se to podařilo. Tím je zaručena rychlá odezva.
Na odboru pro zpracování vnitřních událostí tuto událost převezmou a nejprve zjistí, kolik činností je třeba pro dokončení operace provést. Každou z nich pak přidělí k vyřízení jinému úředníku – všichni pak pracují současně na co nejrychlejším dokončení zpracování. První z nich třeba najde všechny automatické akce, které se mají spustit (pro výjezd právě této techniky, v tomto čase, v kontextu tohoto typu události …) a požádá o jejich provedení odbor automatických akcí. Druhý aktualizuje počet volných řidičů na stanici. Další zjistí, zda je k této technice přiřazen spojový prostředek typu navigace a pokud ano, tak předá na navigační server, který se o toto zařízení stará, příkaz k výjezdu.
A tak dále, a tak dále, a tak dále …
Úprava první
Po nějaké době provozu se ale ukázalo, že při větším počtu současných výjezdů (živelné pohromy, zátěžové testy, …) server nepracuje tak, jak by měl. Analýzou jsme zjistili, že dochází k zablokování odboru pro zpracování vnitřních událostí – všichni úředníci již vykonávali nějakou činnost a pro obsluhu nově příchozích událostí zde již nebyli žádní volní. Zkoumali jsme tedy, co všichni dělají a ke svému údivu jsme zjistili, že předávají zprávy navigačním serverům.
Dalším měřením jsme zjistili, že některým navigačním serverům trvá převzetí takovéto zprávy (příkaz k výjezdu, změny stavu událostí, polohy vozidel ostatních složek, …) i jednotky sekund (v běžném stavu se jedná nejvýše o stovky milisekund). Pokud bylo v krátkém časovém úseku třeba předat zpráv více, tak všichni úředníci čekali na to, až navigační server jejich zprávu převezme a nemohli tedy začít zpracovávat další čekající události.
Jako řešení jsme vytvořili nový odbor pro komunikaci s navigačními servery a k němu frontu zpráv, které je na ně třeba předat.
Úředníci z odboru vnitřních událostí tak sami zprávy nepředávají, ale jen je zařadí do fronty k odeslání. To je samozřejmě provedeno výrazně rychleji (v řádu milisekund). Tím jsme zachránili tento odbor (který tvoří jádro celého serveru) a problém jsme odsunuli na odbor nově vzniklý.
Při dalším zátěžovém testu se prověřilo, že řešení bylo úspěšné – k zablokování aplikačního serveru již nedocházelo. Objevil se ale nový problém – výrazně se zhoršilo doručování zpráv na navigační servery. V novém odboru byl totiž jen jeden úředník – nechtělo se nám plýtvat silami na tak jednoduchou činnost jakou je předávání zpráv.
Dále byl ve frontě požadavků zaveden čistící mechanizmus – pokud v ní zpráva čeká již déle než 29 sekund, tak je odstraněna jako již neaktuální. Bez tohoto mechanizmu by docházelo k zahlcení fronty již neaktuálními zprávami, zatímco nové by obsluhovány nebyly.
Úprava druhá
Protože úředník na novém odboru byl jeden pro všechny servery, byly pomalou odezvou jednoho ze serverů postiženy i servery ostatní, byť jejich odezva byla v pořádku, ale zprávy pro ně čekaly ve frontě, než se odbaví dříve vzniklé zprávy pro pomaleji pracující navigační server. Jako další krok jsme tedy ten nový odbor rozdělili na tolik nových, kolik bylo navigačních serverů. Každá konkrétní instance navigačního serveru měla svůj vlastní.
Výsledkem bylo, že ti „nevinní“ již netrpěli za ty druhé a mohli normálně pracovat. Tak se nám podařilo původní problém lokalizovat – jeden „líný“ navigační server už nedokázal zablokovat celý aplikační server ani škodit druhým. Všechny následky svého konání nesl pouze on sám.
Ani to ale nebyl samozřejmě stav, kterého bychom chtěli dosáhnout. Tím je bezproblémová spolupráce se všemi spolupracujícími servery. Pokusili jsme se tedy domluvit s výrobcem toho problémového – tato snaha byla ale bohužel pouze jednostranná. Museli jsme tedy i nadále postupovat jednostranně. Cesta prodloužení „čistící“ doby na více než 29 sekund se nám nelíbila – celý mechanizmus čištění by přestal být funkční. Zvolili jsme tedy jedinou zbývající cestu – posílili jsme odbor pro komunikaci s tímto serverem o nové úředníky.
Úprava třetí
V současné době tedy na odboru předávání zpráv pro navigační server jednoho konkrétního výrobce pracuje v potu tváře 10 úředníků. Snad to bude stačit. V bratrských odborech na stejnou práci stačí jeden úředník … který většinu času tráví ve stavu čekání na další činnost. A pak že existuje nějaká spravedlnost … ještě že si ti úředníci nemohou stěžovat – fragmenty programového kódu zatím ještě odborové hnutí nezasáhlo.