У листопаді 2007 року я запустив Siege для статичної сторінки rudjuk.kiev.ua: 300 віртуальних користувачів протягом однієї хвилини. За моїм тодішнім спостереженням, процесори були завантажені приблизно на 10–20%. Журнал показує 34910 hits, 583.78 trans/sec та нуль невдалих транзакцій.
Умови та журнал вимірювання
У команді -c300 задає кількість імітованих користувачів, -t1M — тривалість, а -d1 — паузи між діями. Такий сценарій потрібно відрізняти від безперервного потоку запитів без затримок. Нижче — повний вивід Siege 2.65b1 з цього запуску.
root@titan-r:~# siege -d1 -t1M -c300 rudjuk.kiev.ua
** siege 2.65b1
** Preparing 300 concurrent users for battle.
The server is now under siege...
Lifting the server siege... done. Transactions: 34910 hits
Availability: 100.00 %
Elapsed time: 59.80 secs
Data transferred: 846.01 MB
Response time: 0.01 secs
Transaction rate: 583.78 trans/sec
Throughput: 14.15 MB/sec
Concurrency: 3.33
Successful transactions: 35063
Failed transactions: 0
Longest transaction: 0.16
Shortest transaction: 0.00Як читати ці результати
Параметр 300 віртуальних користувачів не слід ототожнювати зі значенням Concurrency 3.33 у звіті: кількість налаштованих учасників і виміряна одночасна активність — різні величини. Пауза між запитами також впливає на профіль навантаження. Також у первинному журналі Transactions і Successful transactions відрізняються: 34910 та 35063. Ці значення збережено без виправлення. Тоді я порівнював це з невдалим для мене сценарієм Joomla на 300 користувачів і був задоволений статичною сторінкою. Проте різні сценарії не є чистим порівнянням CMS. Невисоке завантаження процесорів також не доводить, що єдиним обмеженням залишалася оперативна пам’ять.
Параметри інструмента описано в офіційному посібнику Siege. Для власного порівняння слід узгодити тестовий ресурс, набір URL, затримки та тривалість і зберігати версію інструмента разом із результатами.
Немає коментарів:
Дописати коментар