Ir gadījumi, kad izstrādātie veiktspējas testi nenosedz visas iespējamās slodzes kombinācijas. Kā rezultāta mēdz rasties negaidītas ātrdarbības problēmas.
Piemērs “no dzīves” - ir divi procesi, no kuriem pirmais periodiski raksta tabulā – atsevišķi nekādas performance problēmas nerada. Otrs process nepārtraukti lasa no tabulas, pēc optimizācijas (indeksi, pieprasījumi) arī problēmas nefiksējas. Tomēr praksē, kad abi šie procesi mijiedarbojas tiek novērots spēcīgs veiktspējas kritums – serveris periodiski “aizrijas”, jo veidojas daudz lock-u konkrētajā konfigurācijā (MyISAM), kas nav īpaši veiksmīgi izvēlēta.
Stāsta morāle ir, ka saskaldot problēmu apakš-problēmās var viegli palaist garām “kombinētu problēmu” efektus, kas parādās tikai reālā ekspluatācijā pīķa slodžu laikā. Lai iegūtu derīgus rezultātus pirmkārt ir svarīgi izveidot atbilstošus testus.
Testu izstrāde
Nevērīga testu scenāriju izstrāde ved uz nerelevantu rezultātu iegūšanu, kas rezultātā neļauj atrast problemātiskās vietas. Parasti tiek izmantota sekojoša metodika:
- Pirmajā tuvinājumā izmantojot vienkāršus rīkus (apachebench, siege) šauro vietu atrašana.
- Testa parametru izstrāde konkrētu šauro vietu veiktspējas mērīšanai, lai būtu iespēja veikt salīdzinošus mērījumus.
- Šauro vietu veiktspējas mērīšana izmantojot sarežģītākus rīkus, kas spēj simulēt slodzi, kas ir tuva reāliem pieprasījumiem.
Kad punkti 1-3 ir iteratīvi izstaigāti līdz labu rezultātu iegūšanai atsevišķos testos ir jāizstrādā testi, kas veic visa servera daļu vienlaicīgu testēšanu ar slodzi, kas ir tuva reālai pīķa slodzei. To var izdarīt ar Tsung slodzes testēšanas rīku. Problēma, protams, ka šādu apjomīgu testu izstrāde ir visai darbietilpīga.