Latência e SQL Connections over WAN de fibra - Aplicativo E-manage

1

Estou hospedando um banco de dados do servidor SQL criptografado (SQL Server 2012) em um host VMware no meu local em Salt Lake. O tubo de dados do My Salt Lake é de 100 Mbps em fibra via Comcast. Meu lado da Phoenix tem 50 Mbps em fibra via Cox. Minha latência entre sites é de 45 ms. Cada escritório tem cerca de 40 usuários. 20 usuários estão entrando em nosso aplicativo E-manage da Phoenix e 20 ou mais estão logando do lado de Salt Lake.

Os usuários de LAN de Salt Lake que utilizam o E-manage não têm problemas de velocidade, no entanto, os usuários da LAN do Phoenix relatam acesso lento ao trabalhar com o aplicativo E-manage. O desenvolvedor acha que o problema decorre do uso da virtualização (VMWare ESxi 5.5). Quando examino a utilização de recursos do VMware e da minha SAN, vejo que todos os recursos (CPU, RAM, etc.) estão basicamente inativos. Eu tive relatórios de largura de banda para Cox e Comcast e minha utilização de largura de banda está dentro dos limites normais. Não tenho outros problemas com lentidão dos aplicativos internos que uso.

Eu abri os tíquetes com a Comcast e a Cox para ver o que pode ser feito para reduzir a latência de 45ms para os 20s de baixa 20s. Eu sinto que, fazendo isso, faria a diferença. Estou executando aceleradores de WAN em ambos os lados da rede para acelerar o tráfego TCP e estou excluindo o tráfego do SQL. Para descartar a rede Phoenix, pedi a um usuário que conectasse um laptop diretamente ao circuito de fibra Cox e depois utilizasse o E-manage. Mesmos resultados O tempo de resposta foi lento. Eu tenho um túnel IPSec entre sites e para excluir o túnel IPSec, alterei o registro DNS da Phoenix para utilizar o registro A público que eu configurei para o meu servidor SQL.

Pedi ao desenvolvedor de SQL o contato de outro cliente para que eu possa ver como é o tempo de acesso / resposta ao executar a partir de um site remoto. Eu ficaria feliz em fornecer informações mais detalhadas para ver se algo está faltando. Eu também considerei a execução de consultas SQL independentes de um terceiro para ver qual é a integridade do meu servidor SQL e se há algum problema potencial com o banco de dados SQL.

Eu tenho um servidor físico que estou preparado para configurar para ver se isso faria a diferença.

Aguardo ansiosamente comentários, sugestões e conselhos.

Obrigado antecipadamente - Troy

    
por troyB 03.07.2015 / 18:20

1 resposta

2

IMO (e eu não tenho nenhum dado empírico) executando um aplicativo baseado em SQL em uma conexão WAN raramente funciona bem do ponto de vista do desempenho. Existem várias camadas que podem estar causando o problema para os usuários da WAN que não serão facilmente percebidos pelos usuários da LAN; latência de aplicativos, latência de criptografia SQL, latência do sistema operacional, latência de rede etc. Tudo o mais sendo igual, a latência da rede é, como você disse, provavelmente onde o problema se manifesta de uma perspectiva do usuário. A menos que você tenha uma conexão dedicada e privada entre os dois locais do mesmo provedor, provavelmente não há nada que qualquer um possa fazer. Eles só têm controle sobre sua própria infra-estrutura de rede, não uns com os outros e certamente não há nada entre os dois. Sua latência não me parece tão terrível, então eu estaria interessado em saber que tipo de perda de pacotes (se houver) ocorre entre os dois escritórios.

    
por 03.07.2015 / 20:07