nějak tady blbne highlighter...

-k samotnému algoritmu

nediv se, když sekvenčně děláš 66 požadavků
3min/66≃ 3 sekundy ... pokud je to někde v zámoří, tak to není nic neobvyklého na druhou stranu jsem si teď ověřil, že požadavek trval 1.2 sekundy
==> zjisti, zda api umožní hromadný dotaz,
==> nebo dotazy paralelizuj, ale jelikož je php zastaralý jazyk, buď to jde pomocí fórků nebo curl_multi. Případně pro PHP existuje React.php.

Další průšvih je, že se během skriptu 66x zapisuje do databáze. Proč to neudělat chytře a hodnoty si uložit nejdřív do pole a a pak udělat jeden velký update v databázi. (Paradoxně tohle možná bude pracnější, než současné ledabylé řešení) A ne vždy je to taky lepší řešení a je třeba provnat pro a proti

Dál v ukázce postrádám ošetření chyb...
A o úrovni kódu( používání CDD - CopyPaste Driven Development) už vůbec...
Tohle je přece mnohem hezčí:

    $cron = array(
	'online'  => '0',
	'viewers' => '0'
	);

if($json_array['stream'] != NULL){
	$viewers = $json_array['stream']['viewers'];

	$cron = array(
		'online'  => '1',
		'viewers' => $viewers
		);     
}
dibi::query('UPDATE users SET', $cron, 'WHERE twitch=%s', $channelName);

To by byl asi taková do očí nejvíc bijící nešvar...


Další věc - aplikace není vůbec rozvrstvená...(v v souborů napevno používáš dibi jako úložiště)- to ti nevadí?

A pak samotné podstatě problému: Jak jsem snažil pochopit, ty jsi psal, že by dobré řešení byl CRON, ale ty jsi místo něj udělal to, že při každém požadavku se získávají data?! To se pak nediv. Když už je zvoleno takovéhlýhle otřesný způsob, tak by stálo aspoň ty data načítat jen, pokud jsou starší než 15 minut.
To lze implementovat pohodlně v nette, že si vytvoříš CacheStorage a nad Ním cache a záznam do ní uložíš s flagem EXPIRE. Nebo pokud nette neznáš, změnit kód stránky tak, že tam vložiš podmnínku, zda jsou , že pokud jsou data starší něž načtený timestamp, tak že je načteš z webu a uložíš kamkoli a s tím současně zapíšeš aktuální timestamp.