Pisanje modula za NGINX

[mikikg]

Evo jeda tema koja mozda nekome nekada moze da zatreba.

Imao sam potrebu da nekoliko RPi-a trebaju da razmenjuju izmedju sebe relativno malu kolicinu podataka (<1KB) ali relativno cesto (do 25 puta u sekundi) u lokalnoj mrezi (nema internet/gateway).

Posle vise pokusaja kako to da resim odlucio sam se da izaberem NGINX (HTTP protokol) koji se pokazao kao uzezetno robustan, pouzdan i veoma veoma brz.
Samo mali podsetnik, NGINX web server gura odprilike 50% kopletnog interneta na svetu ukljucujuci i ovaj nas forum, to je veoma ozbiljno napisan software!

Pre ovoga sam pokusavao da resim to sa *nix soketima, stalna veza koja pljucka te podatke ali se ispostavilo da je prilicno slozeno da se "izhendluju" sve potrebne situacije oko toga, radi ali je sklono zaglupljivanju.

Dakle izbor je pao na NGINX i varijanta da se napravi poseban modul za njega kako bih dobio na brzini procesiranja i to uvezano preko "deljene memorije" (/dev/shm), bez i jednog FILE I/O, dakle da sve radi iz memorije ...

I napravio sam tako, relativno je prosto da se odradi, sve se moze spakovati u jednu C skriptu i jedan konfiguracioni fajl za sam modul.

Naravno neophodno je da osposobite okruzenje za prevodjenje celog NGINX source code-a + instalirati zavisne biblioteke (zlib, OpenSSL opciono, i jos nesto zaboravih sta) i konfigurisati build skriptu da povuce i source za taj nas modul.
Dodatno je potrebno samo podesiti nginx.conf da "slusa" na odredjenoj IP : PORT i postaviti "rutu" da "gadja" nas nov modul.

Na ovoj adresi ima primer sa source-code za "hello_world_module":
https://github.com/perusio/nginx-hello-world-module

E sad, drugi deo price je "klient", sta tu sad staviti ali na srecu tu nisam imao mnogo nedoumica bar kada je HTTP u pitanju i za te potrebe sam iskoristio libCurl, cuvena biblioteka koja je isto jako dugo u upotrebi i to je "proverena stvar", sa tim nema brige.

Zakljucak, NGINX za server i libCurl za klienta radi odlicno. Dobio sam rezultate reda 1-2ms za potrebno vreme procesiranja celog upita (slanje upita i citanje odgovora) sto meni zavrsava posao a oslonio sam se na proverene/poznate biblioteke koje se lako implementiraju.

Koga interesuju vise detalja oko ovoga neka slobodno pita ...

[ddanijel]

Svidja mi se ovo i kao ideja i kao realizacija. Nisam imao pojma da nginx i uopste http moze da se upotrebi za nesto gde je bitna brzina i nesto u da kazemo real time-u .

[mikikg]

Nije lose, tu je izvucen maksimum iz NGINX ali sa tim smo na nivou HTTP koji ima svoje prednosti i mane, u sustini bitno je da je HTTP maksimalno "ispeglan" kod njega, to je proslo testova i testova i testova i testova .... Ko nadje bilo kakvu gresku u NGINX taj je "baja" : )

E sad probao sam naravno i ZeroMQ, jb*** radi cca 10x brze od NGINX, dobar je protokol i super je sve ali sa tim se vracam na pocetak price sa socketima i koneckijama i hendlovanjem i to je muka ... U sustini sa ZeroMQ bi trebalo to da se napravi, to je napravljeno bas za ovo sto meni treba aliii nije jednostavno, za NGINX modul sam potrosio mozda 2 sata da napisem funkcionalni prototip sa uvezanim stvarima koje mi trebaju i to je to, sve mi izhendlovano na drugom mestu samo srz logike je u toj jednoj C skripti i to je vec meni totalno cool ...

[mikikg]

U primeru sa linka nije iskoriscena funkcija za inicializaciju modula, prazna je, to je odlicna stvar za moje potrebe jer tu odradim potrebne inicializacije ka SHM memoriji i tu se vise ne prolazi, kasnije u run-time po upitu samo citam iz SHM i punim izlazni buffer servera i to je to, to tu potreseno vreme ne moze da se detektuje u ukupnom odgovoru, verovatno je reda <100us, mrzelo me da detaljnije merim jer nisam imao potrebe, sve ostalo je hendlovano u onih 1-2ms i to mi zavrsava posao jer imam "prozor" od 40ms u koji moram da se upakujem da bi ta neka moja skalamerija radila u realnom vremenu.

[1van]

Btw, za ove projekte gde ti uređaji rade "nonstop" bez restarta, koje SD kartice koristis?

[mikikg]

U poslednje vreme ne vodim nesto specialno racuna, ima raznih kartica, dobre kartice (za industrisku upotrebu) moraju da se potraze, zadnje koje sam koristio iz te serije su bile neke Panasonic SLC (single-layer), ima sad i drugih a vidim da im se drze cene, te panasonic su kostale oko 100E za 8GB, isto kao i ove nove ...

https://eu.mouser.com/Embedded-Solutions...55Z1yxxwsy

Bas nesto radim sa tim karticama, i ove Panasonic koje imam rade najbolje od svih uSD koje sam probao, sve akcije se desavaju "momentalno" kako da opisem, sve druge kartice nesto cekaj da presnimi, cekaj da oslobodi uredjaj, kod ove sve to radi cak-cak-cak ...

To je pola price, druga polovina je ko/kad/koliko cesto pise u uSD memoriju, u sustini ta uSD kartica treba da nosi sistem i kada se ucita program u RAM da se posle toga vise ne koristi, da se izbegne logovanje i pisanje u razne fajlove, sve moze iz memorije da radi a moze i ponekad da se zapise nesto, ne tako cesto ...

Za vrlo frekvetno logovanje mora da se koristi nesto drugo, ne uSD nego se zakaci FRAM SPI memorica i tu pisi i citaj do mile volje, dokle ima mesta, moze (8, 16, 64KB, ne monogo) i na svaku sekundu da upisujes i da racunas radne sate i ostale real-time parametre ...
Ta FRAM memorica ce da ostane uz RPi dokle god radi, nadzivece RPi, nadzivece i uSD sto je primarno bitno, ona ostaje uz masinu kao trajna (izmenjiva) memorija i tu stoje bitni podaci o masini (podesavanja, parametri itd), sve moze da se zameni samo da se taj sadrzaj ne zagubi i onda si cool ... sutra ce da bude neki RPi 5, 6 i tako dalje a podaci i dalje tu i operativni

[ognjan]

Za vrlo frekvetno logovanje mora da se koristi nesto drugo, ne uSD nego se zakaci FRAM SPI memorica i tu pisi i citaj do mile volje, dokle ima mesta, moze (8, 16, 64KB, ne monogo) i na svaku sekundu da upisujes i da racunas radne sate i ostale real-time parametre ...
Ta FRAM memorica ce da ostane uz RPi dokle god radi, nadzivece RPi, nadzivece i uSD sto je primarno

Taj FRAM spajas na SPI port RPI-ja ?

[mikikg]

Za vrlo frekvetno logovanje mora da se koristi nesto drugo, ne uSD nego se zakaci FRAM SPI memorica i tu pisi i citaj do mile volje, dokle ima mesta, moze (8, 16, 64KB, ne monogo) i na svaku sekundu da upisujes i da racunas radne sate i ostale real-time parametre ...
Ta FRAM memorica ce da ostane uz RPi dokle god radi, nadzivece RPi, nadzivece i uSD sto je primarno

Taj FRAM spajas na SPI port RPI-ja ?

Da, na postojeci SPI port.

Evo ovde jedan demo program za to povezivanje:
https://github.com/mikikg/rpi_spi_fram

[mikikg]

Mali update na temu sa nekim prakticnim rezultatima.

Raspberry Pi 2 Model B v1.1, sa podignutim NGINX i custom modulom moze da "namiri" na primer 5 klienata od kojih svako osvezava sa 100Hz podatke i prenosi po 20KB u paketu, bez lagova, konstantne perfomanse i to sve radi sa zauzecem do max 55% od CPU stim da smo iskoristili skoro sav LAN trafick (20KB * 100 * 5 = 10MB/s tj oko 100MBit/sec) i to sve na istom RPi na kome zakacen touch displej i vrti nekakav GUI koji kuva preko 100% na momnete na jednom core-u, GUI ne primecuje nikakvo zauzece od ovog NGINX koji radi punom parom za sve pare

[mikikg]

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

[mikikg]

Svidja mi se ovo i kao ideja i kao realizacija. Nisam imao pojma da nginx i uopste http moze da se upotrebi za nesto gde je bitna brzina i nesto u da kazemo real time-u .

Koristi se to dosta, za sve i svasta, radi to lepo i brzo i softtware koji to prati je sad prilicno robustam i ispeglan, zato je popularan i koriste se kako u produkciji tako i za male "ARMiće" i DIY projekte koji guraju lokalno nesto, ne mora da bude HTML, to nema veze sa ovom pricom, a moze i da gura HTML/JS i sta god vec sto inace radi  ...
Ja sam samo iskoristio suv bazican HTTP a HTML i sve ostalo PHP, NodeJS, Python, Mongo, Elastic, MySQL, Angular ili sta vec totalno preskocio jer mi ne treba za ovu konkretnu potrebu ...

https://www.nginx.com/blog/nginx-and-iot...-for-mqtt/

[1van]

NGINX Hardening Cheatsheets: https://github.com/trimstray/nginx-admins-handbook