Я тестировал свой сайт с помощью apache ab и заметил, что время отклика сильно различается при запуске ab на сервере и удаленном запуске ab на клиентском компьютере.
Итак, в чем самая большая разница между запуском ab на сервере и удаленным запуском ab. Время тратится на чистую транспортировку?
Задержка и пропускная способность сети.
Мы написали хорошую статью о параллельном / нагрузочном тестировании с помощью 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/
Как вы предположили, разница связана с передачей через Интернет с удаленного клиента на веб-сервер.
Так что при тестировании всегда полезно попытаться смоделировать ваш пользовательский опыт. Итак, что я делаю, я пытаюсь запустить разные тесты на основе географического местоположения моих посетителей, чтобы узнать, как они воспринимают сайт. Например, если большинство моих посетителей из США, я запускаю оттуда экземпляр EC2 и запускаю тест.
Исходя из этого, вы можете решить развернуть какой-либо CDN, если это необходимо.
Да, причина в другой сетевой ситуации. HTTP-запрос обычно требует двух циклов приема-передачи (для очень небольшого запроса и ответа):
Client -> Server, SYN
Server -> Client, SYN/ACK
Client -> Server, ACK and HTTP request
Server -> Client, HTTP response
Итак, пингуйте свой сервер и удвойте это количество; это время, которое в среднем добавляется к каждому запросу.
Вы можете включить поддержку HTTP с помощью -k и исключить из уравнения один из этих двусторонних запросов, но он все равно будет медленнее, чем локальные запросы из-за задержки.