Moravian instruments
Vyhledávání
Hlavní menu
Hlavní stránka
O společnosti
Stažení software
Stažení dokumentů
Obchodní partneři
Registrace
Vstup pro partnery
Produkty
Programový systém Control Web
Strojové vidění VisionLab
Kamery DataCam a  osvětlovače DataLight
Průmyslový počítačový systém DataLab
Vědecké CCD kamery
Speciální technika
Ceník
Aktivace produktů
Control Web online
Služby
Školení
Zakázková řešení
Podpora


Hlavní stránka  Produkty  Programový systém Control Web  Články

Co dělat, když je aplikace příliš náročná na čas
 Každý autor aplikací v prostředí Control Web se alespoň jednou setkal s chybou „Aplikace je příliš náročná na čas“. Co tato chyba vlastně znamená? Jak zjistit, která část aplikace způsobuje zatížení aplikace? Jak aplikaci upravit, aby tato situace již nenastávala? S těmito dotazy se na nás zákazníci často obracejí. V následujícím článku se na tyto otázky pokusíme odpovědět.

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í:

  1. 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.

  2. Jádro spočítá, za jak dlouho má být tato aktivace provedena a na zbývající čas usne.

  3. Jakmile nastane čas aktivace, jádro se probudí a aktivuje všechny přístroje, které má z předchozího kroku nachystané.

  4. 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:

  1. Jádro si u každého přístroje vypočítá nejbližší okamžik, kdy má být aktivován.

  2. Jádro spočítá, za jak dlouho má být provedena nejbližší aktivace a na zbývající čas usne.

  3. Jakmile nastane čas aktivace:

    1. Ze všech přístrojů jádro zjistí seznam kanálů, které budou přístroje chtít číst.

    2. Zahájí čtení těchto kanálů

    3. Pokud to některé kanály vyžadují, počká na dokončení komunikace

    4. Jádro aktivuje všechny nachystané přístroje

  4. 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.

 
 | O společnosti | Produkty | Podpora | Stažení software | Stažení dokumentů | 
Moravské přístroje, a.s., Masarykova 1148, Zlín-Malenovice, 76302