Como medir corretamente o desempenho da rede do SQL Server em uma WAN?

Question

Estamos no processo de migração de vários servidores para um data center diferente. Como uma medida de intervalo, movemos um conjunto de servidores da web para o novo data center e deixamos seus servidores SQL de suporte em nosso datacenter existente. Os dois estão conectados através de um link WAN via VPN.

Como faço para medir corretamente o impacto desse movimento no desempenho e na utilização da rede?

Meu objetivo final é dobrar:

• Para avaliar o impacto no desempenho do usuário final dos sites
• Determine se precisamos gastar mais em um tubo maior

Answer 1

Desculpe, se você não estava fazendo isso antes, você não tem como saber o impacto depois. Você teria apenas os números "depois".

Dito isso, você deve medi-lo a partir do front-end usando uma ferramenta que age como um usuário, acessando o site e medindo o tempo para concluir operações específicas. Essa é a abordagem que a maioria das suítes de "monitoramento de desempenho" faz. Ou você pode fazer com que seu aplicativo da web mantenha seu próprio registro do tempo necessário para executar consultas e transações SQL, mas você teria que inserir isso nele e manter os dados em algum lugar.

Além disso - o problema típico com um link de WAN entre o aplicativo e o banco de dados é a latência, a largura de banda não disponível; portanto, comprar um tubo maior não dá a você nada, exceto uma fatura maior. Mas isso é realmente fácil de descobrir agora - rode NTOP ou NetFlow ou algo no seu dispositivo WAN (ou até mesmo em seus servidores web) e veja quanta largura de banda está sendo usada pelo protocolo SQL.

    

Answer 2

Qual é o seu objetivo aqui? Você está tentando medir a velocidade para comparar diferentes links / sites? Ou você está estudando se algo funciona adequadamente para suas necessidades?

Se o primeiro, então, como mfinni diz, se você não tem os números "antes", então você não terá nada para comparar os números "depois" com. Simples assim.

Se este último, então simplesmente criar um 'Acordo de Nível de Serviço' justo para desempenho e disponibilidade com base no que os usuários precisam para as mudanças, e apenas medir o desempenho e a disponibilidade adicional em relação ao SLA.