La un mail asa lung cred ca se justifica un raspuns scurt, mai ales ca e vineri.
Ce vrei tu se cheama in limba engleza "throttle". Bafta! ;) 2015-06-12 12:36 GMT+03:00 Alex 'CAVE' Cernat <[email protected]>: > ca tot imi plac mie filmele sf, sa mai vin cu o intrebare sf, asa cum > m-am obisnuit > > se da o aplicatie in php care pe alocuri, in functie de url / parametrii > primiti face niste operatii cpu & memory intensive, operatii care > dureaza (posibil si zeci de secunde), si din pacate de abia cand ajung > in php pot sa imi dau seama daca e groasa sau nu; problema e prima > cerere de fiecare fel, dupa aia se considera ca datele prelucrate se vor > lua din cache; nu se poate face cache warmup, pentru ca sunt prea multe > posibilitati, nu stiu exact de ce anume voi avea nevoie (depinde de ce > url-uri vin) > > ca sa dau un exemplu, ca tot parca e bacul zilele astea, sa zicem > calcularea procentului de promovabilitate sau mai stiu eu ce note in > functie de numarul de la pantofi; iau datele, le incarc in memorie (ca > am zis ca e memory intensive), le prelucrez si dau mai departe > rezultatul, dar si cache-uiesc rezultatul > > avem urmatoarele situatii: > 1. forta bruta / "a-m loat baq" / impuscati programatorul > - vin 100 de cereri simultan, se executa toate cele 100 in paralel, s-a > umplut memoria, s-a dus serverul pe apa sambetei, da-i buton etc etc > - se poate limita numarul de procese php, pana la urma scap de > sucombarea serverul, dar nu scap de denial of service (am toate > procesele de php care rasnesc in draci procesand datele) > > 2. prelucrare unica per clasa > - vin 100 de cereri, se executa prima, restul stau si asteapta sa > primeasca rezultatul de la primul (semafoare, mutex, gearman, cozi etc., > solutii sunt destule) > - partea buna: un singur proces, recte php-ul sau cui i-o fi trimis task > munceste, restul asteapta toti cu sufletul la gura rezultatul > - ok, performantele s-au imbunatatit, dar nu scap de denial of service, > decat poate daca maresc numarul de procese php; in cazul asta e ok, dar > daca vin multe cereri diferite, iar n-am facut nimic, ajung tot la > denial of service > > 3. pun un varnish in fata > - care cu minime configuratii in loc sa faca 100 de cereri pentru > acelasi url va face una singura si o va servi mai departe de 100 de ori > - insa daca spre exemplu se schimba putin url-ul, sau spre exemplu am o > cerere de genul 'doar pantofii cu numerele 41 si 42' (adica ceva ce > poate fi bagat in aceeasi oala cu cererile de dinainte, dar asta o stiu > de abia cand ajung in php, nu mai inainte) > > si pentru ca m-am ametit si eu de cate am scris, CE VREAU DE FAPT: > o modalitate eficienta de a-i specifica fie varnish-ului fie direct > apache / nginx via fastcgi ca acum cutzu rezultate pentru prelucrarile > mai lungi, dar sa incerce mai tarziu, FARA ca clientul sa stie asta; > consider ca in anumite conditii prefer mai multe cereri http decat > procese php care stau degeaba in timp ce alte cereri nu pot fi > indeplinite pentru ca nu exista sloturi de executie necesare > m-am uitat prin specificatiile fastcgi si nu am gasit nimic de genul > asta cu retry, din momentul in care s-a dat controlul / comanda la php > nu stiu cum sa mai ajungi inapoi la apache > mai vorbeau unii de redirect temporar in $url&try=%try+1, dar > retry-after nu e luat in considerare, si nu fac decat un dos cu metoda > asta, pana va da eroare de prea multe redirecturi > retry-after merge in schimb cu 503, dar cred ca doar googlebot-ul ia > headerul respectiv in considerare, browserul normal ramane cu eroarea > singura solutie viabila de la care as putea porni ar fi returnarea unui > cod aiurea de 5xx catre varnish, iar pe baza codului respectiv el sa > faca retry; din pacate insa cica e nerecomandat sa pui chestii gen > sleep() prin vcl-uri, trebuie sa aprofundez cum si de ce, pentru ca mi > se pare cam aiurea sa nu existe chestii simple de delay (am vazut chiar > niste exemple in care trimiteau la niste php-uri cu sleep() in ele, come > on ... deja astea sunt sf-uri mai mari decat sf-urile mele) > dupa cum ziceam, clientul trebuie sa fie agnostic de ce fac eu in spate, > el face o cerere si fie primeste rezultat, fie eroare; altfel, mergea > probabil cu un websocket ceva > > Alex > > _______________________________________________ > RLUG mailing list > [email protected] > http://lists.lug.ro/mailman/listinfo/rlug > _______________________________________________ RLUG mailing list [email protected] http://lists.lug.ro/mailman/listinfo/rlug
