Мне любопытно узнать, насколько я могу положиться на результаты тестирования нагрузки с помощью Siege и AB. Я понимаю, что они не учитывают статические активы (изображения, JS, CSS), но, полагая, что все эти вещи подаются с CDN, если Siege/AB говорит мне, что я могу обслуживать 200 одновременных пользователей, есть ли какая-то причина, по которой я должен Не доверяешь? Разве я не рассматриваю какие-либо другие факторы, такие как любые ограничения, которые может испытывать машина, работающая в тесте?
Насколько точны испытания с помощью Siege и AB?
Ответ 1
Вот довольно хорошая статья, в которой обсуждаются проблемы, связанные с попыткой тестирования типа Siege или ab, а затем абстрактно, насколько хорошо ваш веб-сайт или веб-сайт будет работать под нагрузкой.
Вот несколько палочек с этой страницы, которые вызывают проблемы с этим типом тестирования:
-
Siege не является репрезентативным для реального пользователя (или нескольких пользователей) на вашем сайте. Он может загружать только исходный код ответа и HTML, а не все другие элементы на странице (изображения, CSS, JS или другой статический контент) - настолько эффективно, что он только проверяет производительность PHP.
-
Он также имеет очень ограниченную поддержку сессий/файлов cookie, отсутствие поддержки для конвейерной обработки и базовой поддержки HTTP/1.1. Нагрузка, которую он генерирует, не похожа на загрузку реального пользователя, поэтому пока она хороша для быстрой справки после изменений; он действительно не указывает, что что-то изменится для пользователя в реальной жизни.
-
Осада легко одурачить, она не может различать статический файл (т.е. чистый HTML файл) или динамический файл (то есть динамическую страницу PHP Magento). Поэтому, если вы используете какой-либо статический прокси файл, результаты сразу же искажаются. На данный момент - вы будете тестировать только прокси-сервер кэширования, а не скорость доставки.
-
Таким образом, те, кто использует Varnish, Nginx caching, mod_pagecache, могут просто просто закрепить страницу в кеше, и вы увидите время рендеринга sub 20ms. Если вы используете Varnish, а затем используете Siege для проверки производительности - вы можете также загружать изображение, а не URL категории, поскольку он дает точные результаты.
-
Тестирование удаленных серверов практически бессмысленно, так как это тест concurrency (т.е. сколько запросов может быть выполнено повторно), непосредственным узким местом является сетевое соединение между двумя машинами. Задержки и накладные расходы TCP/IP - это то, что делает тестирование удаленного сайта совершенно бессмысленным, малейшая перегрузка сети между одноранговым узлом между двумя серверами сразу же снизит производительность. Итак, что действительно начинает вступать в игру, так это то, как быстро может быть завершено трехстороннее рукопожатие TCP - тестируемый сервер может обслуживать динамическую страницу или статический файл в 0 байт - и вы можете видеть точно такие же показатели производительности, как и Связь является узким местом.
Другая проблема, которую они обсуждают в статье, которая может оказать самое серьезное влияние на общую производительность вашего сайта, - это латентность между вашим сайтом и клиентами, которые к нему обращаются. У них есть хорошее объяснение того, как латентность может влиять на производительность ваших сайтов таким образом, что ваши конечные пользователи будут чувствовать это, но методы тестирования Siege и ab никогда не будут отображаться.
Снова выписывая статью:
Пинг из Великобритании в Великобританию
[~]$ ping www.bytemark.co.uk -c4
PING www.bytemark.co.uk (212.110.161.177) 56(84) bytes of data.
64 bytes from extapp-front.bytemark.co.uk (212.110.161.177): icmp_seq=1 ttl=57 time=2.86 ms
64 bytes from extapp-front.bytemark.co.uk (212.110.161.177): icmp_seq=2 ttl=57 time=2.51 ms
64 bytes from extapp-front.bytemark.co.uk (212.110.161.177): icmp_seq=3 ttl=57 time=2.54 ms
64 bytes from extapp-front.bytemark.co.uk (212.110.161.177): icmp_seq=4 ttl=57 time=2.63 ms
--- www.bytemark.co.uk ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 2.515/2.641/2.869/0.142 ms
Пинг из Великобритании в США
[~]$ ping www.mediatemple.net -c 4
PING www.mediatemple.net (64.207.129.182) 56(84) bytes of data.
64 bytes from mediatemple.net (64.207.129.182): icmp_seq=1 ttl=49 time=158 ms
64 bytes from mediatemple.net (64.207.129.182): icmp_seq=2 ttl=49 time=154 ms
64 bytes from mediatemple.net (64.207.129.182): icmp_seq=3 ttl=49 time=154 ms
64 bytes from mediatemple.net (64.207.129.182): icmp_seq=4 ttl=49 time=154 ms
--- www.mediatemple.net ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 154.155/155.282/158.321/1.802 ms
Вы можете сразу увидеть разницу в производительности. Для этого сингла TCP/IP-соединение с США из Великобритании, потребовалось 156 мс, в 62 раза больше чем на сервер в Великобритании. Это означает, что перед тем, как вы попытаетесь что угодно, максимальная пропускная способность, которую вы можете достичь при осаде за секунду будет составлять около 6 транзакций в секунду из-за задержки только.
Я настоятельно рекомендую прочитать всю статью. Он очень хорошо объясняет ловушки проведения тестирования производительности с помощью таких инструментов, как Siege и ab!