Přijatelná odezva CLI aplikace (diskuse)

[dolik.rce]

Odezva je důležitá, ale nejde stanovit žádné absolutní číslo. I běžnému uživateli je jasné že sort nad souborem s miliony radku bude chvili trvat. U jednoduchych programu je limit uživatelské přívětivosti menší, třeba při spuštění shellu čekám že bude reagovat prakticky okamžitě. Každopádně 0.2s je podle mě úplně v pohodě, pokud to není program který by chtěl někdo použít ve skriptech kde se bude mnohokrát opakovat.

[Jakub Lucký]

Nějak nevidím, jak si z těch naměřených čísel zvládnu udělat představu o přijatelnosti odezvy...

1) Aplikace, která by ty časy simulovala by byla fajn

2) Na co aplikace je by taky bylo dobré vědět (u různých aplikací je přijatelnost odezvy různá)

[xkucf03]

Nasimulovat se to dá třeba takhle:

sleepenh 0.2; echo "hotovo";

[xkucf03]

Ještě upřesnění: vstup se vypisuje průběžně, ne až všechen najednou.

[JS]

Tak kdyz poustim prikaz z CLI, vetsinou tusim, co to dela a kolik dat to sezere. Pokud je to trivialita, cekam okamzitou (tedy do tech 0.2s) odezvu. Pokud to trivialita neni, pocitam s tim a je mi to jedno (konecne - vzdycky je tu Ctrl-z a bg).

[Heron]

Osobně za limit odezvy u interaktivního programu (CLI, GUI, WEB) považuji 200ms. Při delších časech se již ztrácí pocit okamžité reakce. Reakcí však nemusí být nutně konečný výsledek, většinou stačí to, že se něco začne dít. Pokud ten tvůj CLI program vypisuje něco postupně a jako celé to trvá těch max 430ms, tak je to ok.

[w4rr10r]

Když nedostanu odezvu v řádu sekund, znejistím, zda se provádí, co se provádět má, nebo se někde něco zacyklilo. Takže jsem radši, když se vždycky něco vypisuje (aspoň do logu). Takhle jsem se natrápil s jedním programem, který sice dělal, co měl dělat, ale trvalo mu to asi minutu (pro libovolný vstup), přičemž mi chvíli trvalo, než mě napadlo, že to nemusí být chyba, ale prostě pomalost programu.

[Kvakor]

Ano, výpis stavu je pro podobně dlouhopracující programy asi nejlepší řešení. Nemusí být defaulně zapnutý (protože unixovou filosofií je hlásit jen varování a chyby), ale měl by jít zapnou parametrem (většinou -v). Není důležité, aby byl výpis přesný (u některých věci jde čas odhadnou těžko), ale aby byl alespoň nějaký.

Alternativní řešení u programů pracujících se soubory je zjišťovat pozici v souboru (který může mít i desitký GB) pomocí hodnost v /proc/[pid]/fdinfo v řadku pos, který soubor to je jde zjistit přes symlinky v /proc/[pid]/fd.

Jinak obecně bohužel nelze zjistit, jestli se program říznul nebo mu to jen dloho trvá, i když u některých to zjistíte, až když dojde swap a zaúřaduje OOM killer

[xkucf03]

Případně, pokud program čte vstup průběžně, se dá použít příkaz pv – měřit, kolik proteklo rourou.