11-11-2020, 03:58 AM
Ovo sa NGINX + libCurl i HTTP je ispalo sjajno, posebno sto se tice samog HTTP protokola koji zavrsava mnogo lepo posao, HTTP je samo dodatak na moje "raw" podatke i HTTP u svom hederu ima sve bitne informacije, doduse u tekstulanom obliku ali takav je kakav je, na primer u HTTP 1.1 je uveden podrazumevani "keep-alive" heder koji znaci da klient moze samo jednom da se konektuje (da otvori socket) i posle moze da salje uzastopno upite preko istog soketa, ne mora da se ponovo otvara sto stedi jos dodatno vreme. Postoji time-out koji je standardno 30 sekundi, to znaci ako klient ne salje nikakve zahteve na toj soket konekciji u tom trajanju server ga diskonektuje.
Sam klient moze da postavi svoj time-out na recimo 20ms da dodatno detektuje svoju stranu konekcije.
I najlepsa stvar, mada je limitirano na minimalno 1 sekundu (moze vise), libCurl ako se koristi sa keep-alive i server posalje na primer Header Refresh 1, klient ce automatski da se refresuje posle 1 sekunde, tehnicki ne mora da se radi eksplicitno puling nego server diktira osvezavanje po predefinisanom protokolu i libCurl i NGINX to sve mnogo lepo kontaju i potpuno se rezumeju i na kraju to radi mnogo lepo, najnoviji rezultati sa "keep-alive" na istom RPi 2 su 1562req/sec sa paketima od 1KB i 426req/sec sa 20KB paketima sto daje oko 1.6MByte/sec za prvi slucaj i nekih 8.3MByte/s za drugi slucaj, zauzece RPi CPU ~50%.
Sam klient moze da postavi svoj time-out na recimo 20ms da dodatno detektuje svoju stranu konekcije.
I najlepsa stvar, mada je limitirano na minimalno 1 sekundu (moze vise), libCurl ako se koristi sa keep-alive i server posalje na primer Header Refresh 1, klient ce automatski da se refresuje posle 1 sekunde, tehnicki ne mora da se radi eksplicitno puling nego server diktira osvezavanje po predefinisanom protokolu i libCurl i NGINX to sve mnogo lepo kontaju i potpuno se rezumeju i na kraju to radi mnogo lepo, najnoviji rezultati sa "keep-alive" na istom RPi 2 su 1562req/sec sa paketima od 1KB i 426req/sec sa 20KB paketima sto daje oko 1.6MByte/sec za prvi slucaj i nekih 8.3MByte/s za drugi slucaj, zauzece RPi CPU ~50%.