Administrace komentářů

Tak situace se trosku zmenila. Doslo k upgradu CPU (passmark +25% per core, +aes), modifikace VM z 12 na 20core, ram z 64GB na 96GB a vysledky...

1] dump postgresql se zkratil z 2.5h na 1.5h

2] debug databazovych volani na testovane strance - pripojeni se zkratilo na 1/2, celkova doba dotazu zhruba na 1/2~2/3 puvodnich casu (tohle kolisa dle zateze), generovani stranky se zkratilo (dle zateze) pri 1 klientovi z 1.5s na 0.9s.

Tak se pustilo siege/ab...a vysledky se moc nezlepsily (v tomhle pripade je i vliv, ze stroj nebyl odstaven od pristupu zvenci na dobu testovani).

1] 10 klientu ~ 10 tps, load 14

2] 15 klientu ~ 12.36 tps, load 21

3] 20 klientu ~ 12.79 tps, load 30

4] 25 klientu ~ 14.19 tps, load 34, atd., kolisani mezi 12-14

To same zhruba i pres ab. Jeste to zkusim z jineho virtualu, pokud by treba byl nejaky problem na tom, z ktereho se to pousti. Pokud jsem koukal pres htop na load, tak jsou vytizena vsechna jadra (~75% user, ~25% system). Podle htop navic (meni se to) bylo ve stavu Running napr: 13x apache, 4x psql, 1x netdata (mensi priorita). 1x htop, zbytek je Sleep.

Pokud jsem testoval ten 1 radkovy php skript, tak tam je strop zhruba 1100 tps.

0] 5 klientu ~ 400 tps

1] 10 klientu ~ 720 tps

2] 15 klientu ~ 994 tps

3] 20 klientu ~ 1083 tps

4] 25 klientu ~ 1091 tps, atd., kolisani kolem 1100

V tomhle pripade byla vsechna jadra vytizena kolem 50% (~95% user). Pri testech pres ab pri jednom klientovi ten skript probehne za 8~27ms (<90% 8~9ms), pri 15 klientech jiz 47~117ms (<90% 44~69ms).

Je to nejake podivne...