My "answer" is lengthy - they key is to not confuse 'throughput' with
'bandwidth' - although 'bandwidth' can be a limiting factor
In short, your throughput may be limited even though your bandwidth is
not saturated.
Eu tive que ajudar as pessoas a entender o impacto das pilhas de aplicativos multicamadas.
Para o aspecto das comunicações TCP, faço uso de diferenças em RTT (round-trip-time).
Para a camada única, você pode comparar o endereço IP local (em uma NIC) com lo0 (loopback).
Para camadas múltiplas, compare / calcule os endereços "mais distantes", por exemplo, multicamada pode ser duas VMs no mesmo host ou podem ser hosts diferentes no mesmo datacenter ou podem estar em diferentes centros de dados (talvez apenas 500 metros de distância, mas ainda diferentes).
FYI: para muitas aplicações, as diferenças de RTT são insignificantes, mas para aplicações que fazem 10-100 de milhares de pequenas mensagens para o tempo de RTT do aplicativo podem se tornar um gargalo.
(Eu vi situaltions onde o "lote levou quase 6 horas a mais em multi-tier quando o RTT foi 0,25 miliseg mais longo, comparado ao single-tier)
Então, teste simples:
O
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
E meu programa de monitoramento é o tcpdump - com a opção -ttt
-ttt
Prints a delta (in microseconds) between current and previous line on each dump line.
A microsecond is an SI unit of time equal to one millionth (0.000001
or 10−6 or 1/1,000,000). That is, 1000 microseconds == 1 millisecond.
Portanto, em duas janelas diferentes, tenho o tcpdump em execução:
Para os horários "locais":
tcpdump -i lo0 -n -ttt porta 80
E para o "remoto"
tcpdump -I en1 -n -tttporta 80
Nos dados abaixo - o objetivo não é fazer nenhuma análise, mas mostrar como você pode identificar as 'diferenças' no tempo necessário para que as transações sejam concluídas. Quando a taxa de transferência de um aplicativo é uma transação serial - a taxa de transferência por "segundo | min | hora" é afetada pelo tempo total necessário para "respostas". Eu achei isso mais fácil de explicar usando o conceito de RTT - tempo de ida e volta.
Para uma análise real, há coisas adicionais a serem observadas. Assim, as únicas linhas que mostrarei são o handshake de TCP inicial, o primeiro pacote de saída e o ACK de retorno. Para a comparação, compare os tempos delta de quanto tempo antes que a "resposta" retorne.
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
observe o 01.XXXXXX - para o segundo suspenso na interface "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
máquina virtual no mesmo host - observe que o tempo começa em 00.000000 - o primeiro pacote é exibido (e o 01.XXXXXX para os outros dois endereços abaixo)
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
meu roteador - fora do host, não uma máquina virtual.
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
mesma conexão que 192.168.129.72, mas isso é 'ocupado' enquanto '72' está ocioso. Eu espero que os apertos de mão iniciais sejam quase idênticos
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>
vários saltos
este é o mesmo host, o mesmo resultado do apache, mas agora através da interface externa (6 IP hops, em vez de direta) - agora você pode o efeito de longa distância RTT. (p.s., eu modifiquei o endereço IP ligeiramente). Mais importante - observe que há dois pacotes de saída após o aperto de mão inicial antes do primeiro ACK após o retorno de um handshake.
Então, em vez de 25msec RTT, pense que o RTT é de 250 microssegundos, comparado a 25 microssegundos - e você tem 500k transações (que chegam a apenas 120 a 125 segundos extra em relação ao local, e o throughput é, imho, comparável Mas com transações de 50M (como eu tive em uma situação da vida real) você ganha um adicional de 12500 segundos - o que acrescenta cerca de 3,5 horas adicionais para "literalmente" o mesmo trabalho (e parte da solução para este caso era fazer os pacotes maior - o tamanho médio era originalmente de 400-450 bytes).
Recall, what I want to show here is a fairly simple way to account for
differences in overall time for an application (batch job) to complete
when comparing multi-tier with single-tier architectures.
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>
Outra coisa que eu "gosto" sobre o uso do tcpdump é que é um programa que geralmente está disponível. Nada extra precisa ser instalado.