Eu tenho um único servidor rodando um aplicativo web .NET e um banco de dados SQL Server (2008 Standard). Estou planejando mover o banco de dados para um servidor separado, mas para provisionar o hardware de rede, gostaria de comparar a taxa de transferência de dados entre o aplicativo da Web e o banco de dados. A porta 1433 pode ser monitorada internamente? Em caso afirmativo, existe alguma ferramenta nativa do Windows 2008 R2 que possa fazer isso ou eu precisaria de algum aplicativo de terceiros como o WireShark? Minha string de conexão está referenciando o banco de dados usando server=localhost, ainda é possível acessar 1433 para ver a largura de banda usada nesta porta?
Essencialmente, estou tentando determinar se preciso de uma conexão Gbit ou 100 Mbit entre o servidor da Web e o servidor de banco de dados. Qualquer pensamento sobre isso seria muito apreciado.
ATUALIZAÇÃO 8 de julho
Eu discuti o que foi dito acima, pois percebo que é amplamente irrelevante. Por alguma razão, pensei que haveria uma grande diferença de custo entre um switch de 100 Mbit e 1 Gbit. Apenas os switches de usuário doméstico baratos são de 100 Mbit. Como outros apontaram, o Wireshark não coletará atividade entre o IIS e o servidor SQL na mesma caixa. Estou colocando um switch gerenciado de 1 Gbit por enquanto e usarei o Wireshark ou o monitoramento integrado no switch para ver o que está acontecendo mais tarde. Não acho que chegará nem perto dos limites de transferência física impostos pelo hardware.
Não conhece nenhum método interno para gravar bytes em uma porta específica; portanto, se você realmente precisa desse nível de detalhe, o Wireshark é uma boa aposta.
Se o servidor for dedicado ao SQL Server, eu estaria razoavelmente confiante de que a maior parte do tráfego na rede estava relacionada, portanto, o contador perfmon
Network Interface\Bytes Total/Secdeve fornecer uma diretriz ampla.Para ser honesto, é um ponto mudo no meu livro. A menos que haja um custo adicional grande e sem sentido para a porta gig onde seus servidores estão hospedados, aceite-o.
Pelo que entendi, você deseja monitorar o tráfego de rede entre um aplicativo da Web hospedado no IIS e no SQL Server, ambos em execução no mesmo servidor. Isso vai ser complicado por algumas coisas:
A maioria dos farejadores de pacotes não oferece suporte ao monitoramento de tráfego em uma interface de loopback como você está usando se seu aplicativo Web se conectar ao SQL Server em localhost ou 127.0.0.1. O Message Analyzer da Microsoft é uma exceção, mas é beta, não parece ter muito em termos de ferramentas de visualização ou análise e não parece ser exportável para um formato que possa ser lido por farejadores de rede com ferramentas decentes de análise de throughput.
O tráfego não será analisável se você estiver usando memória compartilhada ou pipes nomeados locais em vez de TCP para se conectar ao SQL Server.
O Wireshark também não sabe de quais IDs de processo os pacotes foram enviados ou recebidos, o que pode ser um problema dependendo de seus requisitos de filtragem.
O Wireshark possui boas ferramentas de visualização e análise em comparação com outros sniffers de rede, incluindo gráficos de throughput e estatísticas sobre conversas. O que fiz no passado, quando precisava filtrar o ID do processo, era capturar com nmcap ou Network Monitor e, em seguida, importar para o Wireshark para fazer a análise. No entanto, nada disso funcionará se você estiver se conectando por loopback ou por meio de pipes nomeados locais ou memória compartilhada.
Concordo com o conselho de obter apenas um switch de 1 gbps, se possível, mesmo que você não precise dele hoje. Se você não precisar dele agora, poderá precisar mais tarde, e é mais fácil atualizar de maneira planejada enquanto seu aplicativo está funcionando bem do que em uma emergência em que a rede está saturada.
Algumas vezes por ano, encontro um aplicativo da web que consegue saturar um link de 100 mbps para um servidor de banco de dados, então não acho que esse seja um cenário estranho. Muitos dos aplicativos que eu suporte não são bem projetados, portanto, isso pode nunca ser um problema para você se você estiver usando princípios de design de bom senso, como não recuperar resultados gigantescos em todas as visualizações de página.
O DMV
sys.dm_exec_connectionstem estatísticas por conexão para tráfego, incluindo bytes enviados/lidos. Mas ele é redefinido toda vez que uma conexão física é fechada e também é um mau indicador de taxa de transferência, especialmente picos.Dito isto, o tráfego entre cliente e servidor nunca deve ser uma preocupação. Especialmente para um aplicativo da web, onde grandes conjuntos de retorno não são apropriados de qualquer maneira. Muito mais cedo você terá problemas com a taxa de interrupção da placa de rede, não com a taxa de transferência.
No entanto , a taxa de transferência desempenhará um papel importante em muitas das outras atividades relacionadas às operações do banco de dados: