2015-06-12 12:36 GMT+03:00 Alex 'CAVE' Cernat <[email protected]>: > 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 >
Acu serios, ce zici tu aici e o aberatie. Nu poti face queueing in frontend decat daca ai garantia ca e un spike de trafic care o sa treaca. Daca esti slashdotted (sau cum vrei sa chemi fenomenul cand ai o rata incoming de requesturi _sustinuta_ care depaseste capacitatea backendului), mai devreme sau mai tarziu ceva va da pe-afara. Din cauza ca vorbim de web (desi se aplica si la alte medii mai fancy fix aceeasi treaba), cea mai sanatoasa abordare imho e sa-i dai "piua" clientului sa incerce mai tarziu, nu sa-i promiti chestii pe care nu le poti indeplini. Daca n-ai capacitate sa-l servesti secunda asta, de unde stii ca o sa ai secunda viitoare? La scara de timp ceva mai mare (minute), daca esti in ceva cloud poti sa mai spin-up instante (considerand ca bottleneckul tau e ceva scalabil orizontal si nu db sau alt global lock), da' pana atunci tot e bine sa-i dai un Respose: "5xx Mai Baga O Fisa" in loc sa faci cu requesturile alea ca un hamster somalez scapat in depozitul de la nutella. -- P. _______________________________________________ RLUG mailing list [email protected] http://lists.lug.ro/mailman/listinfo/rlug
