Мой «ответ» является длинным - они не должны путать «пропускную способность» с «пропускной способностью», хотя «пропускная способность» может быть ограничивающим фактором
Короче говоря, ваша пропускная способность может быть ограничена, даже если ваша пропускная способность не насыщена.
Я должен был помочь людям понять влияние многоуровневых стеков приложений.
Что касается связи по TCP, я использую различия в RTT (в оба конца).
Для одноуровневого уровня вы можете сравнить локальный IP-адрес (на сетевой карте) с lo0 (loopback).
Для многоуровневой системы вы сравниваете / вычисляете «более удаленные» адреса, например, многоуровневая система может быть либо двумя виртуальными машинами на одном хосте, либо разными хостами в одном центре данных, либо они могут находиться в разных центрах обработки данных. (может быть, расстояние всего 500 метров, но все равно другое).
К сведению: для многих приложений различия RTT незначительны, но для приложений, которые делают 10-100 тысяч небольших сообщений за время приложения RTT, может стать узким местом.
(Я встречал ситуации, когда «многоуровневая партия» занимала почти 6 часов дольше, когда RTT была на .25 миллисекун дольше по сравнению с одноуровневой)
Итак, простой тестовый стенд:
The
for host in 127.0.0.1 192.168.129.63 192.168.129.72 192.168.129.254 192.168.129.71 p5.aixtools.net
do
wget -q http://${host}/ -O - >/dev/null
sleep 1
done
И моя программа мониторинга - tcpdump - с опцией -ttt
-ttt
Prints a delta (in microseconds) between current and previous line on each dump line.
Микросекунда - это единица времени СИ, равная одной миллионной (0,000001 или 10-6 или 1/1 000 000). То есть 1000 микросекунд == 1 миллисекунда.
Итак, в двух разных окнах у меня работает tcpdump:
Для «локального» времени: tcpdump -i lo0 -n -ttt порт 80 И для «удаленного» tcpdump -I en1 -n -ttt порт 80
В приведенных ниже данных цель не состоит в том, чтобы провести какой-либо анализ, а показать, как вы можете определить «различия» во времени, необходимом для завершения транзакций. Когда пропускная способность приложения - последовательные транзакции - на пропускную способность в «сек | мин | час» влияет общее время, необходимое для «ответов». Я нашел, что это проще всего объяснить, используя концепцию RTT - туда-обратно.
Для реального анализа есть дополнительные вещи, которые нужно посмотреть. Итак, единственные строки, которые я покажу, это начальное рукопожатие TCP, а также первый исходящий пакет и возвращаемый ACK. Для сравнения сравните дельта-времена того, как долго «ответ» возвращается.
127.0.0.1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lo0, link-type 0, capture size 96 bytes
00:00:00.000000 IP 127.0.0.1.42445 > 127.0.0.1.80: S 1760726915:1760726915(0) win 65535 <mss 16856,nop,wscale 2,nop,nop,timestamp 1482096651 0>
00:00:00.**000035** IP 127.0.0.1.80 > 127.0.0.1.42445: S 3339083773:3339083773(0) ack 1760726916 win 65535 <mss 16856,nop,wscale 2,nop,nop,timestamp 1482096651 1482096651>
00:00:00.000013 IP 127.0.0.1.42445 > 127.0.0.1.80: . ack 1 win 33688 <nop,nop,timestamp 1482096651 1482096651>
00:00:00.**000014** IP 127.0.0.1.80 > 127.0.0.1.42445: . ack 1 win 33688 <nop,nop,timestamp 1482096651 1482096651>
192.168.129.63
обратите внимание на 01.XXXXXX - на одну секунду сна на интерфейсе «lo0»
00:00:01.006055 IP 192.168.129.63.42446 > 192.168.129.63.80: S 617235346:617235346(0) win 65535 <mss 16856,nop,wscale 2,nop,nop,timestamp 1482096653 0>
00:00:00.**000032** IP 192.168.129.63.80 > 192.168.129.63.42446: S 1228444163:1228444163(0) ack 617235347 win 65535 <mss 16856,nop,wscale 2,nop,nop,timestamp 1482096653 1482096653>
00:00:00.000014 IP 192.168.129.63.42446 > 192.168.129.63.80: . ack 1 win 33688 <nop,nop,timestamp 1482096653 1482096653>
00:00:00.**000010** IP 192.168.129.63.80 > 192.168.129.63.42446: . ack 1 win 33688 <nop,nop,timestamp 1482096653 1482096653>
192.168.129.72
виртуальная машина на том же хосте - обратите внимание, что время начинается с 00.000000 - отображается первый пакет (и 01.XXXXXX для двух других адресов ниже)
root@x063:[/]tcpdump -i en1 -n -ttt port 80
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on en1, link-type 1, capture size 96 bytes
00:00:00.000000 IP 192.168.129.63.42447 > 192.168.129.72.80: S 865313265:865313265(0) win 65535 <mss 1460,nop,wscale 3,nop,nop,timestamp 1482096655 0>
00:00:00.**000125** IP 192.168.129.72.80 > 192.168.129.63.42447: S 916041515:916041515(0) ack 865313266 win 65535 <mss 1460,nop,wscale 2,nop,nop,timestamp 1481318272 1482096655>
00:00:00.000028 IP 192.168.129.63.42447 > 192.168.129.72.80: . ack 1 win 32761 <nop,nop,timestamp 1482096655 1481318272>
00:00:00.**000055** IP 192.168.129.72.80 > 192.168.129.63.42447: . ack 1 win 65522 <nop,nop,timestamp 1481318272 1482096655>
192.168.129.254
Мой роутер - вне хоста, а не виртуальной машины.
00:00:01.005947 IP 192.168.129.63.42448 > 192.168.129.254.80: S 2756186848:2756186848(0) win 65535 <mss 1460,nop,wscale 3,nop,nop,timestamp 1482096657 0>
00:00:00.**000335** IP 192.168.129.254.80 > 192.168.129.63.42448: S 2327415811:2327415811(0) ack 2756186849 win 5792 <mss 1460,nop,nop,timestamp 44854195 1482096657,nop,wscale 2,nop,opt-14:03>
00:00:00.000022 IP 192.168.129.63.42448 > 192.168.129.254.80: . ack 1 win 32761 <nop,nop,timestamp 1482096657 44854195>
00:00:00.**000090** IP 192.168.129.63.42448 > 192.168.129.254.80: P 1:142(141) ack 1 win 32761 <nop,nop,timestamp 1482096657 44854195>
192.168.129.71
то же соединение, что и 192.168.129.72, но оно «занято», а «72» бездействует. Я надеюсь, что начальные рукопожатия почти идентичны
00:00:01.005093 IP 192.168.129.63.42449 > 192.168.129.71.80: S 249227688:249227688(0) win 65535 <mss 1460,nop,wscale 3,nop,nop,timestamp 1482096659 0>
00:00:00.**000072** IP 192.168.129.71.80 > 192.168.129.63.42449: S 1898177685:1898177685(0) ack 249227689 win 65535 <mss 1460,nop,wscale 2,nop,nop,timestamp 1482096104 1482096659>
00:00:00.000022 IP 192.168.129.63.42449 > 192.168.129.71.80: . ack 1 win 32761 <nop,nop,timestamp 1482096659 1482096104>
00:00:00.**000050** IP 192.168.129.71.80 > 192.168.129.63.42449: . ack 1 win 65522 <nop,nop,timestamp 1482096104 1482096659>
несколько прыжков
это тот же хост, тот же результат Apache, но теперь через внешний интерфейс (6 IP-прыжков, а не прямой) - теперь вы можете получить эффект междугородного RTT. (PS, я немного изменил IP-адрес). Более важно - обратите внимание, что после первоначального рукопожатия есть два исходящих пакета до первого ACK после его возвращения.
Итак, вместо RTT 25 мс, подумайте, что RTT составляет 250 микросекунд, а не 25 микросекунд - и у вас есть 500 000 транзакций (что на 120–125 секунд больше по сравнению с локальной, и пропускная способность, imho, сравнима. Но с За 50 миллионов транзакций (как в реальной жизни) вы получаете дополнительные 12500 секунд - что добавляет примерно 3,5 дополнительных часа для «буквально» той же работы (и частью решения для этого случая было увеличение пакетов - средний размер изначально был 400-450 байт).
Напомним, что я хочу показать здесь, это довольно простой способ учета различий в общем времени выполнения приложения (пакетного задания) при сравнении многоуровневых и одноуровневых архитектур.
00:00:01.162974 IP 192.168.129.63.42450 > XX.85.86.223.80: S 1331737569:1331737569(0) win 65535 <mss 1460,nop,wscale 3,nop,nop,timestamp 1482096661 0>
00:00:00.**023962** IP XX.85.86.223.80 > 192.168.129.63.42450: S 3130510306:3130510306(0) ack 1331737570 win 65535 mss 1460,nop,wscale 2,nop,nop,timestamp 1482096106 1482096661,nop,opt-14:03>
00:00:00.000025 IP 192.168.129.63.42450 > XX.85.86.223.80: . ack 1 win 32761 <nop,nop,timestamp 1482096661 1482096106>
00:00:00.000062 IP 192.168.129.63.42450 > XX.85.86.223.80: P 1:142(141) ack 1 win 32761 <nop,nop,timestamp 1482096661 1482096106>
00:00:00.**024014** IP XX.85.86.223.80 > 192.168.129.63.42450: . ack 1 win 65522 <nop,nop,timestamp 1482096107 1482096661>
Еще одна вещь, которая мне «нравится» в использовании tcpdump - это общедоступная программа. Ничего лишнего не нужно устанавливать.