Čeština
Dobrý den, zkousel jsem Teco API - nacitani jedne promenne v intervalu 1 s (GetObject endpoint s parametrem nazvu promenne). Nicmene se hodne casto stava, ze odpoved nestihne do 1 s prijit, casto to foxtrotu trva i 8 s nez posle vysledny json s hodnotou. Pritom se nezda, ze by ethernet rozhrani bylo nejak zahlceno (i kdyz je pripojeny Mosaic), na jiny http dotaz foxtrot reaguje okamzite.. (i kdyz se ceka na vyrizeni dotazu pres Teco API)
V cem muze byt problem a co by mohlo pomoct?
Uz mam upraveny interval, aby nasledujici dotaz poslal az kdyz predchozi bude obslouzen (abych foxtrota na teco api "nebombardoval") ale stale je odpoved celkem na dlouho.. skoro se mi zda, ze je to v takovych nejakych casovych cyklech - kdyz cekam na odpoved > 5 s tak pak to zacne chvili odpovidat vcas nez se to zacne opet zpomalovat - neni to nejakym bufferem v interni implementaci obsluhy Teco Api?
Odpovědi 4
Dobrý den,
na výkon API má vliv více parametrů, nicméně odezvy v řádu sekund by se vyskytovat neměly.
Rychlost API je závislá na počtu proměnných, které API poskytuje, na otočce cyklu PLC, na počtu paralelních spojení. Velký rozdíl ve výkonu je také mezi Foxtrotem řady CP-1xxx a CP-2xxx.
Příčinou dlouhé prodlevy by například mohlo být nezavírání spojení ze strany tazatele, kde by pak došlo k vyčerpání maximálního počtu paralelních spojení, kdy by prodleva byla způsobena čekáním na timeout neaktivních spojení.
Pokud se dotazuje na API z PC bylo by ideální nachytat komunikaci pomocí programu Wireshark, kde bychom viděli, kde k problému přesně dochází.
Dekuji za rozbor. Uzavirani spojeni me nenapadlo, to by davalo docela i smysl. Zkousim vradit nezavisly webserver, takze dotaz sel pres Axios knihovnu (s digest overenim) z NodeJS backendu. Foxtrot je CP-1001.
Potvrzuji, že přesně toto chování jsem pozoroval také. I časy přesně souhlasí. Telefonicky jsem to před několika týdny probíral s panem Nemeškalem a dostal jsem v podstatě stejné rady, jako jsou uvedeny zde. Analýzou kódu jsem zjistil, že hlavní problém asi skutečně bude v (ne)uzavírání spojení, resp. v mém případě v paralelních dotazech vznikajících v asynchronně běžícím kódu. Upravil jsem kód tak, aby volání TecoAPI bylo "serializované" a tím se situace značně zlepšila. Nicméně stále dochází k tomu, že občas Foxtrot s odpovědí zaváhá, byť to už není zdaleka tak často a na tak dlouhou dobu. Mám pocit, že tam stále je "něco", co způsobuje, že se Foxtrot zadrhne, i když "nemá nic na práci". Nemůžu ale vyloučit, že tam dochází k nějaké komunikaci, o které nevím. Mám v plánu to ještě dál zkoumat, ale je to trochu komplikovanější, protože bohužel nejsem schopen komunikaci pomocí programů typu Wireshark monitorovat - klient TecoAPI neběží na PC a Wireshark tak na komunikaci nedosáhne.)
I kdyz jsem pridal frontu na pozadavky teco api a dalsi request provedl az kdyz se predchozi obslouzil, a axiosu nastavil http agenta, tak to stale nebylo ono.
Nakonec jsem poresil tento pravidelny "ping" na zjisteni stavu pres ETH UNI rozhrani. Nastavil jsem si obsluhu pro 3 paralelni spojeni a zatim to vypada ok a chova se to o dost lip na protistrane.
Wireshark na win mi bohuzel z nejakeho duvodu vzdy "vytuhne".. jeste nekdy zkusim stary notebook s linuxem, az si tam rozbeham prostredi s nodejs.
Jinak prozatim mam exportovane pro teco api 3 promenne, jeden timestamp a dvakrat pole struktur.
Vaše odpověď
Pro vložení odpovědi je nezbytné být přihlášený. Pokračujte na přihlášení.