Itt a várva várt megoldás.
Hogy kicsit gonosz legyek, tulajdonképpen mindegy, ahogy mindegy, hogy "járt-e Cecil a Török utcában". Az igazi kérdés nem az, hogy a konkrét esetben mi volt a megoldás (azért meg fogom mondani), hanem az, hogy mi lehet az oka egy ilyen terhelési profilnak, és nyugodtan aludhatunk-e ha ilyet látunk.
A választ a kommentelők megadták: nem aludhatunk nyugodtan, ha nem tudjuk, hogy a rendszer miért viselkedik úgy, ahogy viselkedik, akkor azt ki kell nyomozni, mert ha nem, akkor marad egy adag bizonytalanság: vagy jó a program, vagy csak jónak tűnik.
A konkrét esetben a programban volt egy terhelést figyelő logika, és ha N darab szál aktív volt, akkor nem indított több kiszolgáló szálat, hanem olyan szálakat aktivált (thread pool-ból) az egyes beeső kérésekre, amelyek egyszerűen csak visszavágták, hogy: a gép túlterhelt, időszakosan nem elérhető, próbálja meg később. Mivel ez egy http interfész volt, ezért 503 hibakódot adott vissza.
503 Service Unavailable
Persze közben a gépet egyre jobban terhelte, és hiába jött vissza az 503 nagyon gyorsan a kérések egy kis (és egyre kisebb) százaléka továbbra is jó eredményt adott, de egyre lassabban. Emiatt az átlagos válaszidő nőtt. A szórás persze igen érdekes képet mutatott volna: egy csúcs az 503 válaszokra 1mp-en belül, és egy "normál" eloszlás egyre nagyobb T időpontnál.
A jó válasz itt hangzott el először:
Nuunius · http://r2d2fishtank.blog.hu/2009.06.23. 10:10:11
eszembe jutott, hogy nem volt esetleg nézve h mi az üzenet ami visszajön a kérdésre. Akkor pedig lehet olyan ,hogy sima hibaüzenet jött válaszként, mint a villám. Aztán valahol betelt valami és akkor már nem volt képes feldolgozni a kéréseket...
