| | 283 | == Однесувањето на системот при ненадејно зголемување на сообраќајот |
| | 284 | |
| | 285 | За анализа на однесувањето на системот при ненадејно зголемување на сообраќајот беше извршено сценарио познато како Slashdot effect. Во првата фаза системот беше оптоварен со 10 истовремени корисници во времетраење од 30 секунди, по што следуваше нагло зголемување на оптоварувањето на 500 корисници во следните 30 секунди. Во последната фаза оптоварувањето повторно беше намалено на 10 корисници. |
| | 286 | |
| | 287 | Во првата фаза времето на одговор беше 2.5 секунди со throuhgput 12req/sec и без грешки. Системот работи стабилно и барањата се обработуваат брзо. Потоа во Traffic Spike времето на одговор е 25 секунди со throuhput од 70req/sec. Во оваа фаза може да забележиме некои грешки (2%). |
| | 288 | |
| | 289 | При нормално оптоварување системот покажува стабилни перформанси со ниско време на одговор и без појава на грешки. За време на spike фазата се забележува значително зголемување на времето на извршување на прашалниците, како и мала појава на timeout грешки предизвикани од исцрпување на достапните конекции во connection pool-от. И покрај тоа, PostgreSQL продолжува успешно да обработува голем број барања без целосен прекин на услугата. |
| | 290 | |
| | 291 | Recovery фазата има време на одговор 3 секунди и througput 10req/sec. Во оваа фаза се ослободуваат DB конекциите и CPU оптоварувањето опаѓа. |
| | 292 | |
| | 293 | По намалувањето на бројот на корисници, системот релативно брзо се враќа во нормална состојба. Времето потребно за стабилизација изнесува приближно 10 до 20 секунди, што укажува на добра отпорност на базата кон краткотрајни екстремни оптоварувања и соодветна оптимизација на индексите и SQL прашалниците. |
| | 294 | |
| | 295 | == Failure Recovery Test |
| | 296 | |
| | 297 | Последниот тест ќе биде failure recovery тестот, односно додека работи JMeter ќе го рестартираме PostgreSQL и ќе следиме перформанси. Работиме со 50 корисници, ramp-up од 30 секунди и времетраење од 300 секунди. Околу 2 минути системот си работи нормално и во оваа фаза се измерени време на одговор 120мс и error rate 0%. По 2 минути извршуваме sudo systemctl stop postgresql. По самиот пад request-ите почнуваат да паѓаат и ЈМетер враќа Connection refused и SocketTimeoutException. По 5 секунди системот е целосно недостапно, односно има throuhgput од 0req/sec и error rate 100%. Потоа извршуваме sudo systemctl start postgresql - ова е recovery фаза која трае 14 секунди. Во оваа фаза имаме throughput 78req/sec кој постепено расте и error rate 3% поради backlog. Последната фаза е стабилизација (после 2-3 минути) и има throughput 90 req/sec и error rate помал од 1%. |
| | 298 | |
| | 299 | Од резултатите може да видиме дека recovery процесот е брз, со враќање во нормална состојба за помалку од една минута. Овој тест успешно демонстрира реален failure сценарио и ја потврдува важноста на мониторинг, backup и high availability. |
