Какая разница в работе ab локально и удаленно?
Я тестировал свой сайт с помощью apache ab и заметил, что время отклика сильно отличается при запуске ab на сервере и удаленном запуске ab на клиентском компьютере.
Так что же самое большое различие между запуском ab на сервере и удаленным запуском ab. Время, затрачиваемое на чистую транспортировку?
3 ответа
Задержка и пропускная способность сети.
Мы написали хорошую статью о параллельном / нагрузочном тестировании с помощью Siege (которая очень похожа на AB), особо упомянув локальное и удаленное тестирование.
Вы можете прочитать полную версию здесь:
Тестирование удаленных серверов практически бессмысленно, так как это тест параллелизма (т. Е. Сколько запросов может быть удовлетворено многократно), непосредственным узким местом является сетевое соединение между двумя компьютерами. Задержки и издержки TCP/IP делают тестирование удаленного сайта совершенно бессмысленным, малейшая перегрузка сети между равноправными узлами между двумя серверами немедленно покажет снижение производительности. Итак, что действительно начинает вступать в игру, так это то, насколько быстро может быть выполнено трехстороннее рукопожатие TCP - тестируемый сервер может обслуживать динамическую страницу или статический 0-байтовый файл - и вы можете увидеть точно такие же показатели производительности, как узкое место - связь.
Мы можем показать это с помощью простого пинга. Наши дата-центры расположены в Манчестере, Великобритания, поэтому мы попробуем пропинговать сервер в Великобритании, затем сервер в США и покажем разницу. Оба сервера подключены к Интернету через 100 Мбит соединения.
Пинг из Великобритании в Великобританию
[~]$ 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 --- 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 mstime=2.86 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 --- 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 раза больше, чем для сервера в Великобритании. Это означает, что, прежде чем вы попробуете что-либо, максимальная пропускная способность, которую вы можете достичь в Siege за секунду, составит около 6 транзакций в секунду только из-за задержки.
Давайте проверим это потом...
[~]$ siege http://www.wiredtree.com/images/arrow.gif -c 1 -t 10S -b ** SIEGE 2.66 ** Preparing 1 concurrent users for battle. The server is now under siege... Lifting the server siege...done. Transactions: 50 hits Availability: 100.00 % Elapsed time: 9.89 secs Data transferred: 0.00 MB Response time: 0.20 secs Transaction rate: 5.06 trans/sec Throughput: 0.00 MB/sec Concurrency: 1.00 Successful transactions: 50 Failed transactions: 0 Longest transaction: 0.20 Shortest transaction: 0.19Всего под прогнозируемой цифрой 6 TPS. Но, к сожалению, так будет всегда. Задержка всегда будет разрушать любой тест параллелизма, даже если удаленный сервер способен на гораздо больше. Давайте повторим тот же самый тест с сервера в США, чтобы увидеть, как задержка действительно повлияла на тест. Сначала быстрый пинг,
[~]$ 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=52 time=62.8 ms --- www.mediatemple.net ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3067ms rtt min/avg/max/mdev = 62.872/62.922/62.946/0.029 ms [~]$ siege http://mediatemple.net/_images/searchicon.png -c 1 -t 10S -b ** SIEGE 2.72 ** Preparing 1 concurrent users for battle. The server is now under siege... Lifting the server siege... done. Transactions: 73 hits Availability: 100.00 % Elapsed time: 9.62 secs Data transferred: 0.22 MB Response time: 0.13 secs Transaction rate: 7.59 trans/sec Throughput: 0.02 MB/sec Concurrency: 0.99 Successful transactions: 73 Failed transactions: 0 Longest transaction: 0.14 Shortest transaction: 0.12Итак, у вас это есть, нам удалось удвоить количество транзакций в секунду без каких-либо изменений на стороне сервера, просто используя сервер ближе к тестовому сайту - показывая, насколько чувствительна Siege к задержке в сети.
Осада будет ограничена пропускной способностью, доступной на вашем тестовом сервере и удаленном сервере. Таким образом, как только вы начинаете достигать более высоких уровней пропускной способности, объем загружаемого контента начинает расти. В наших примерах выше 0, 02 МБ было загружено за 10 секунд - это крошечные 0,16 Мбит / с (мегабит в секунду). Но когда вы начинаете увеличивать количество одновременно работающих пользователей, все может радикально измениться, и очень легко насыщать сетевое соединение - задолго до того, как сам сервер достиг своей емкости.
Поэтому, если бы сервер, с которого вы тестировали, имел пропускную способность в 20 Мбит / с, вы, вероятно, видели бы максимум 500 запросов / с на ресурсе 4 КБ, упомянутом ранее.
Содержание взято с http://www.sonassi.com/knowledge-base/magento-kb/why-siege-isnt-an-accurate-test-tool-for-magento-performance/
Да, причиной является другая ситуация в сети. HTTP-запрос имеет тенденцию требовать двух циклов (для очень маленького запроса и ответа):
Client -> Server, SYN
Server -> Client, SYN/ACK
Client -> Server, ACK and HTTP request
Server -> Client, HTTP response
Итак, пингуйте ваш сервер и удвойте его; это время, которое в среднем добавляется к каждому запросу.
Вы можете включить поддержку HTTP с помощью -k и исключить одно из этих циклических обходов из уравнения, но оно все равно будет медленнее, чем локальные запросы из-за задержки.
Как вы и предполагали, разница связана с передачей через Интернет с удаленного клиента на веб-сервер.
Поэтому, когда вы проводите тестирование, всегда стоит попробовать и смоделировать ваш пользовательский опыт. Итак, что я делаю, я пытаюсь запустить различные тесты, основанные на географическом местоположении моих посетителей, чтобы узнать, как они воспринимают сайт. Например, если большая часть моего посетителя из США, я запускаю экземпляр EC2 и запускаю тест.
Исходя из этого, вы можете принять решение о развертывании CDN, если это необходимо.