2015-06-12 13:01 GMT+03:00 Alex 'CAVE' Cernat <[email protected]>: > On 12/6/2015 12:49 PM, Petru Rațiu wrote: > > 2015-06-12 12:36 GMT+03:00 Alex 'CAVE' Cernat <[email protected]>: > > > > > > 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. > ceea ce incerc de fapt este sa nu execut aceeasi operatie (care garantat > va da aceleasi rezultate) de jde ori in paralel (o execut o data si dupa > aia sanatate, datele prelucrate le am deja gata), si in acelasi timp sa > nu blochez servirea altor resurse pentru care ar fi resursele necesare > atata timp cat nu am jde procese executand in paralel operatia mai sus > pomenita > in mod ideal s-ar putea imparti frumos pe pool-uri diferite in functie > de clasele de operatii, dar dupa cum ziceam cat de groasa e treaba pot > sa aflu de abia cand se ajunge in php si se fac pe acolo niste calcule > banale, insa nu inainte bazat strict doar pe url > daca ai tu alte idei, chiar daca e vineri sunt numai ochi si urechi > oricum, mersi de 'trotil', nu cautam in adevaratul sens al cuvantului, > dar macar e un punct de plecare, ca incepeam sa ma invart in jurul cozii > > Pai daca inteleg bine, problema ta este asa: - un anume request foarte popular dureaza X prima oara (dupa un restart sau alt soi de cache invalidation) si Y urmatoarele requesturi venite dupa ce se termina X. X este mult mai mare ca Y.
- problema ta e ca daca nu faci nimic, la o rata externa constanta de N requesturi pe secunda, o sa ajungi la N*X requesturi in-flight (care toate or sa dureze X, presupunand ca nu te viziteaza OOM killer de la N*X*ram_per_thread) care or sa mai dureze inca cel putin X pana se termina si raman doar requesturi de-alea cu Y. Chestia asta va produce in grafice ceea ce in limbajul de specialitate se cheama "rechini" (de-aia care inoata de la dreapta la stanga prin timeseries). - ca sa-ti protejezi backendul (sau ce crapa cand aripioara de rechin nu mai incape de tavan) trebuie sa limitezi requesturile in-flight, i.e. sa-i zici aluia care le accepta sa faca throttle la maxim atatea in-flight requests (mai putin decat N*X si mai mult decat N*Y, in orice caz undeva la 85% din valoarea unde te calca OOM-ul). - da, e adevarat ca poti face queue la request in balancer sau ceva (unde hopefully consuma mai putine resurse decat atunci cand se executa), si da, pe hartie pare obvious ca o fractiune din X plus Y este in mod normal mai scurt decat 2X, (mi-e lene sa desenez pozele cu rechinul), da' ai niste probleme noi: - rechinul ala de N*X ti se muta in bufferul de requesturi pending al balancerului - nu stii sigur care sunt situatiile in care iti apare problema asta, cum ziceam, poate nu X e ala care creste, ci N, iar la N nu ai garantii ca se termina asa repede. - ca atare e mai bine sa tratezi requestul atunci cand iti vine (am mai mult de Z requesturi in flight? return 500) decat sa-l pui intr-o coada care ar face lucrurile mai complicate fara vreun beneficiu concret. Daca stii momentul cand X-ul ala creste (gen, ai restartat memcache-ul sau ceva de genul) si stii si care-s requesturile alea populare si grase, poti face chestii gen pre-warming la cache, sa zicem ceva de genul: - pornesti un memcache nou in paralel cu cel vechi - il setezi pe un mediu de prerelease (www-preheat.cave.ro) - dai cu jmeter sau curl sau altceva in mediul de prerelease cu un singur request (i.e, N = 1/X) - mai dai un request sa vezi ca a durat Y si nu X - cei doi pasi dinainte se pot repeta pt. mai multe timpuri de requesturi populare (cu N suficient de mare) - schimbi cache-urile intre ele. Sau ofc, faci mentenanta and shit la ore la care n-ai trafic asa mare, deci N mic, deci N*X mic, deci rechinasi mici si manageable. Hai gata ca deja se transforma in powerpoint :) Sper ca descrierea rechinilor a fost suficient de vie sa nu fie nevoie sa-i desenez, da' uite aici cativa: https://flic.kr/p/a4hseC -- P. > 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
