printf(" SaltwaterC ");

Deși titlul pare forțat, proiectul pomenit acolo are un potențial mare atâta timp cât este utilizat cum trebuie. Singurele probleme sunt toate aceste primadone, așa zișii programatori auto-proclamați, ce maxim au idee despre despre ceva scripting într-un limbaj cu tipuri dinamice de date, dar în momentul în care vine vorba de muncă adevărată sau a proiecta un algoritm, dispar. Nu susțin faptul că sunt marele guru ce s-a născut cu tastatura în mână, nu sunt fluent în ANSI C, căci despre acesta este vorba, dar (pe testate) am putut observa potențialul unei astfel de soluții. Deci se adresează programatorilor. Programatorilor ce nu se ascund de pointeri (pe care, recunosc, încă nu-i stăpânesc), programatorilor ce au idee despre cum funcționează platforma pe care rulează aplicația și nu se ascund sub încă un nivel de abstractizare [insert smart-ass name here], etc. Din această categorie recomand “What every programmer should know about memory“, chestie pe care vreau să o parcurg pe îndelete pe când voi avea timp.

Deci ce este acest G-WAN? Pe scurt, în cele aproximativ 120 kile de binar se găsește un web server brutal de rapid și un început de application server, practic suport pentru servlet-uri scrise în ANSI C, compilate dinamic, după metoda edit & play folosită de PHP-iști. Și evident, caching, acea sperietoare de “web developers”, altfel nu ar fi fost chiar atât de rapide.

Am urmărit îndeaproape proiectul de pe la v1.0.3 deoarece mi s-a părut interesantă prezentarea, dar fără aplicabilitate momentană “in real life”. Între timp aplicatia a mai crescut în valoare, iar platforma s-a modificat din Windows (la acea dată) în Linux. Autorul se săturase de limitările din kernelul Windows, limitări ce se găsesc și în kernelul Linux, dar sunt mai sus.

Nu vorbesc din citatele autorului G-WAN despre aceste limitări. Le-am testat pe propria piele. Fie că am executat fractalul lui Mandelbrot (servletul fractal.c disponibil în arhiva de distribuție), fie că am executat problema despre care vorbeam aici, atât implementarea brută cât și cea eficientă, pe un quad-core (C2Q Q9400) și Apache Bench pe localhost am stat în jurul valorii de 69000 req/s. Da, vorbesc de o aplicație, unde fractalul este cu ordin de complexitate mare comparat cu problema numerelor. Dar cu toate acestea, throughput-ul servlet-urilor a fost apropiat ca valoare. Deci există o limitare, dincolo de eficiența algoritmului și a puterii de procesare necesare.

Printre altele, nu a fost nici o limitare de lățime de bandă. Rulând teste de conținut static, am obținut aproximativ 1.2 GiB/s la o concurență suficient de mare, înainte ca ab să înceapă să dea timeout-uri și erori de conectare. Da, 1.2 GiB/s prin interfața de loopback. Aici se adaugă doar efortul de encapsulare, decapsulare și fragmentare a pachetelor din moment ce MTU este mare comparat cu o “rețea normală”, dar totuși cu o valoare implicită de 16436 pe care nu am încercat să o mânăresc și nici nu știu să fi mânărit vreodată prin setările de la lo. Testele dinamice nu se apropiau de această lățime de bandă, de altfel, conținutul static la 1.2 GiB/s abia urca pe la 20000 req/s, deci o limitare de bandă era mult mai evidentă în cazul acestui tip de conținut, față de un servlet.

Singura problemă ce am observat-o a fost una de scalabilitate pe mai mult de două nuclee de procesor. G-WAN lansează un număr de thread-uri egal cu numărul de nuclee, dar din cele 4 pe care le-a lansat, doar primul și ultimul încărcau procesorul în timp ce 2 și 3 frecau menta în idle. Cel puțin așa raportează htop pus în modul threaded la listarea proceselor din sistem.

De altfel, la capitolul conținut static nu am observat o viteză mărită cu ordine de magnitudine față de nginx, ci doar o viteză de ordinul procentelor mai mare, dar totuși vizibilă. La capitolul aplicații dinamice este zona unde strălucește, deși încă mai are puțin până în zona “production ready”, în sensul că momentan lipsesc două chestii mari și late. Prima chestie este renunțarea la privilegiile elevate dacă rulează ca network daemon, unde pentru a folosi portul 80 este nevoie de privilegii de superuser – sau să se apeleze la hack-uri precum NAT prerouting în iptables ori *inetd – nerecomandate. A doua chestie este suportul pentru reverse proxy. Din moment ce codul existent nu se transformă peste noapte în ANSI C, eventual ANSI C optimizat la sânge, G-WAN va putea fi folosit, cândva, pe post de frontent web server într-o arhitectură multi-tier.

Configurația este … ce configurație? De fapt până și pentru virtual hosting se folosește un sistem de “convention over configuration” ce simplifică la maxim treaba, ceea ce face web serverul foarte sysadmin friendly. Singurele chestii mai sofisticate sunt maitenance script-ul și acele handlers, chestii ce necesită cunoștinte de ANSI C înainte de a te apuca să le folosești. Cam toate chestiile minime în accepțiunea unui web server modern sunt acolo inclusiv gzip, activat automat în funcție de tipul de conținut. Restul … sunt specificații, mai mult sau mai puțin interesante.

Update: săpând puțin prin web, am dat de CTPP ce se laudă că are interfață pentru C, chestie ce ar putea satisface nevoile de template engine. Încă nu am renunțat la gândul de a încerca o chestie implementată sub formă de bibliotecă/biblioteci compilate din moment ce acea compilare dinamică nu are suport de optimizare de aia șmecheră cum are gcc, MongoDB sau ceva asemănător pentru persistență și un servlet pe post de front controller.