Abychom správně pochopili, co se děje v přetížené aplikaci, budeme
muset začít alespoň krátkou teorií o tom, jak v Control Webu pracuje
časování přístrojů. Nejdůležitější (z hlediska časování) částí Control
Webu je jádro systému. Jádro má na starosti veškeré
komunikace a především řízení časování přístrojů. Rozhoduje a plánuje,
kdy budou pracovat jednotlivé přístroje. Přístroje mohou vykonávat
svoji činnost periodicky (podle nastavení v parametrech přístroje)
nebo od události (například vyvolané příkazem send nebo změnou dat).
Okamžiku, kdy má přístroj vykonávat nějakou činnost, říkáme
aktivace přístroje.
Základní (pro začátek zjednodušený) postup aktivace
přístrojů je následující:
Jádro si u každého přístroje vypočítá nejbližší okamžik, kdy
má být aktivovány. Potom najde přístroj s nejmenším časem, tedy
přístroj, který má být aktivován nejdříve. Takovýchto přístrojů může
být několik, pokud mají všechny stejný čas následující
aktivace.
Jádro spočítá, za jak dlouho má být tato aktivace provedena a
na zbývající čas usne.
Jakmile nastane čas aktivace, jádro se probudí a aktivuje
všechny přístroje, které má z předchozího kroku nachystané.
Po skončení aktivace pokračujeme znovu bodem 1 (vypočítáme
nejbližší okamžik aktivace přístrojů)
Časovému intervalu, kdy se postupně aktivují přístroje naplánované
na stejný okamžik, říkáme časový krok jádra.
Všechny přístroje vykonávají svou činnost v jednom prováděcím toku
(anglicky thread). To znamená, že přístroje se aktivují postupně jeden
za druhým. Nikdy nemůžou běžet dva přístroje zároveň i pokud běží
Control Web na počítači s více jádry CPU.
S těmito znalostmi si nyní můžeme ukázat, kdy nastane situace
„aplikace je příliš náročná na čas“.
Budeme mít aplikaci s jedním přístrojem, který bude aktivován
každou sekundu. Bude-li pro svoji činnost přístroj potřebovat
například 0,5s, aplikace běží bez problémů.
Pokud se z nějakého důvodu činnost přístroje protáhne, například na
1,5s, aplikace již nepoběží tak, jak autor zamýšlel. Přístroj nebude
aktivovaný každou jednu sekundu, ale po 1,5s. Jádro systému bude dělat
nepřetržitě jeden krok za druhým.
Při skončení časového kroku jádro spočítá čas následující aktivace
přístroje. Zjistí, že tento čas je v minulosti. Přístroj měl být
aktivován dříve. Jádro tedy udělá okamžitě další časový krok. Přístroj
bude aktivován později, než autor aplikace požaduje. Říkáme, že
přístroj se dostal do skluzu. Velikost skluzu přístroje je
možné spočítat - po první aktivaci bude skluz 0,5s. V naší aplikaci se
skluz bude neustále zvětšovat.
Pokud skluz není trvalý, aplikace je navržena s dostatečnou
rezervou a zatížení je tedy jen krátkodobé, aplikace se ze skluzu
vzpamatuje - skluz dožene.
Vrátíme se nyní k naší původní aplikaci, kde jeden přístroj
aktivován každou 1s potřebuje 0,5s pro svoji činnost. Pokud se z
nějakého důvodu jeden krok protáhne na 1,5s, aplikace se dostane do
skluzu. Pokud ale následující kroky trvají zase 0,5s, aplikace skluz
dožene a dále běží v pořádku.
Krátkodobý skluz je stav, který může nastat i v dobře navržených
aplikacích, a pokud aplikace neřídí proces, který by vyžadoval přesné
časování, nemusí být krátkodobý skluz na závadu. Aplikace by měla být
vždy navržena s dostatečnou rezervou časového kroku.
Čas, který potřebují přístroje ke svojí činnosti, musí být menší
než perioda jejich aktivace.
Aplikace ve skluzu. Příčina č. I. Aktivita přístrojů.
Jak jsme si ukázali na předchozích příkladech, jednou z možných
příčin skluzu aplikace je situace, kdy aktivita přístroje (nebo
několika přístrojů) vyžaduje delší čas, než je k dispozici. U
takové aplikace se musíme zamyslet, jestli není možné upravit
procedury nebo parametry v přístrojích tak, aby jejich činnost
nebyla tak náročná. Nebylo by možné napsat určitý algoritmus
efektivněji? Další možností je prodloužit periody aktivace
některých přístrojů. Často je však nutná kombinace obou přístupů,
tedy prodloužit periody a opravit algoritmy v přístrojích, aby
byly efektivní.
Zjistit, jak je na tom aplikace s nároky na čas, nám pomůže
ladicí okno s informacemi o časování aplikace.
Vidíme zde délku časového kroku jádra, to znamená jak dlouho
trvá činnost přístrojů. Rezerva časového kroku jádra je doba, kdy
jádro spí, čeká na následující časový krok. Obě hodnoty jsou zde
průměrné a okamžité. Ve větších aplikacích jádro vykonává velké
množství kroků různé délky a okamžitá hodnota se velmi rychle
mění. V tom případě se musíme orientovat podle průměru.
V ladicím okně také vidíme čas spotřebovaný jednotlivými
přístroji a také počet kroků, které přístroje strávily ve skluzu.
Při ladění aplikace náročné na čas, musíme procházet přístroje v
ladicím okně a hledat, kde by bylo možné ušetřit chybějící
čas.
V aplikaci, která se dostává do skluzu, může být jeden přístroj
způsobující skluz. Ten vyžaduje naši pozornost. Nebo, a to je
častější, je zde obrovské množství přístrojů, které jsou
nenáročné, ale v součtu způsobí skluz aplikace. Je na místě se
zamyslet, jestli není možné vynechat časování přístrojů například
na skrytých panelech.
V aplikacích, které nám posílají zákazníci, se velmi často
setkáváme se zbytečně krátkou periodou časování přístrojů.
Například přístroj, který zobrazuje aktuální hodinu, nemusí být
časovaný jednou za sekundu.
Aplikace ve skluzu. Příčina č. II. Komunikace.
Existuje ještě jedna příčina zdržování aplikací, a to je čekání
na dokončení komunikace externích datových elementů (např.
kanálů).
Vzhledem k tomu, že počítače jsou většinou čím dál tím
rychlejší, vlastní aktivita přístrojů nebývá většinou příčinou
nestíhání aplikací. Mnohem častěji je příčinou skluzu čekání na
„něco“ mimo aplikace. Může to být třeba vykonání SQL dotazu na
serveru nebo nejčastěji čekání na dokončení komunikace.
Na začátku článku jsme si řekli, že jádro systému
Control Web je zodpovědné za aktivací přístrojů a řízení
komunikace. Abychom pochopili, jak komunikace zdržují běh
aplikace, budeme si muset rozšířit popis časového kroku jádra z
minulé kapitoly:
Jádro si u každého přístroje vypočítá nejbližší okamžik,
kdy má být aktivován.
Jádro spočítá, za jak dlouho má být provedena nejbližší
aktivace a na zbývající čas usne.
Jakmile nastane čas aktivace:
Ze všech přístrojů jádro zjistí seznam kanálů, které
budou přístroje chtít číst.
Zahájí čtení těchto kanálů
Pokud to některé kanály vyžadují, počká na dokončení
komunikace
Jádro aktivuje všechny nachystané přístroje
Po skončení aktivace pokračuje zpět bodem 1.
Tento popis kroku jádra je pořád ještě značně zjednodušený.
Není zde například zápis kanálů.
Klíčový je pro nás bod „Počká na dokončení
komunikace“. Kdy a jak se čeká na dokončení komunikace
kanálů? Čekání na dokončení komunikace určuje atribut
timeout každého kanálu. Tento atribut říká jak dlouho
bude jádro systému čekat na dokončení komunikace. Pokud je timeout
nastavený na 0 (což je výchozí stav), na kanál se nečeká. Timeout
je maximální doba, kterou jádro čeká.
Chování aplikace se tak může dramaticky změnit, pokud odpojíme
komunikační linku a některé zařízení, s nímž aplikace komunikuje,
není dostupné. Komunikace, která trvala několik málo ms, se naráz
natáhne na celou délku timeoutu a aplikace se dostane do skluzu.
Proto je vždy nezbytně nutné testovat aplikaci i v situaci, kdy
komunikace s připojenými zařízeními selhávají.
Je zřejmé, že v některých aplikacích může být nevýhodné, aby
čekání jednoho přístroje na „jeho“ kanál zdržovalo běh ostatních
přístrojů a tedy celé aplikace. Myslím, že zvídavému čtenáři,
který se dočetl až sem, můžeme naznačit, že tato část jádra
systému bude v Control Webu 8 kompletně přepracována a umožní
nezávislé čekání jednotlivých přístrojů.
V Control Webu 7 máme několik možností, jak
aplikaci upravit:
Nestačilo by zkrátit timeout kanálů?
Zvážíme, jestli je skutečně nutné čekat na přečtení
aktuální hodnoty. Nemůžeme použít hodnotu z minulé
komunikace?
Pokud skutečně potřebujeme vykonat nějakou činnost po
dokončení komunikace, nepomohlo by nám aktivovat přístroj od
změny dat (zahájení čtení vyvolá např. periodicky datová sekce,
jakmile nová hodnota dorazí, změna dat způsobí aktivaci
přístroje)
Přístroj pouze zahájí čtení a ukončí svoji činnost. Po
dokončení komunikace pokračuje v dalším časovém kroku ve
zpracování v událostní proceduře datového elementu. Aplikace
nemusí čekat, pokud jsme schopni reagovat na událost dokončení
komunikace později na jiném místě.
Není perioda komunikace zbytečně vysoká? Například
venkovní teplota se nemění tak rychle, aby bylo nutné ji číst
10x za sekundu.
S informacemi o náročnosti komunikace nám opět pomůže ladicí
okno. U každého kanálu zde vidíme počet požadavků pro čtení i
zápis a průměrnou dobu komunikace.
|