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 RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
