Přijatelná odezva CLI aplikace

3.1.2012 10:02 | Přečteno: 1510× | IT obecně | poslední úprava: 3.1.2012 11:50

Zajímalo by mne, jakou odezvu považujete za přijatelnou, pokud jde o programy spouštěné interaktivně na příkazové řádce (používá se typicky v rouře, čte vstup, něco s ním dělá a vypisuje na výstup)

Nejde mi až tak o nějaké hodnocení efektivity zpracování dat, ale spíš o subjektivní „prožitek uživatele“ – jestli se mu s tím pracuje dobře, není otrávený, že aplikace je pomalá atd.

Naměřené hodnoty (příkazem time):

real    0m0.127s
user    0m0.108s
sys     0m0.032s

Jsou to tedy desetiny vteřiny. Při zpracování 100× většího vstupu (a tím i výstupu) jsem naměřil:

real    0m0.282s
user    0m0.232s
sys     0m0.064s

Pro 1000× větší výstup:

real    0m0.433s
user    0m0.568s
sys     0m0.044s

(počítač je tři roky starý notebook, žádný superstroj)

P.S. původně jsem to chtěl dát do poradny, ale potřebuji anketu, takže je z toho nakonec blogový zápisek

       

Anketa

Komentáře

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