O front-end e o banco de dados do meu site são separados em dois servidores, conectados por 1000M LAN.
Acho que o tempo de resposta de quase todas as consultas é superior a 800 ms. Posso garantir que minha consulta está correta porque quando eu implanto isso em um único servidor o problema não aparece.
site/asp.net banco de dados 2.0/sql server 2000
Responder1
Se o seu DNS estiver causando um atraso de 800 ms para (o que deveria ser) um endereço IP em cache, há algo seriamente errado com a configuração da sua rede. NA MINHA HUMILDE OPINIÃO. Você pode ver se isso é um problema usando o ping.
Use traceroute para garantir que os pacotes estejam usando uma rota eficiente entre os dois computadores. Isso é fácil de fazer, então vale a pena tentar antes de mexer em outras coisas. Se houver muitos saltos na rota, talvez mais de dois ou três, encontre um cara da rede e pergunte por que isso acontece.
Ao tentar solucionar problemas de rede SQL, é melhor usar uma consulta muito simples, como "SELECT GETDATE()", e usar uma ferramenta de consulta simples como SQLCMD.EXE. A consulta simples significa que o servidor não terá que gastar muito tempo analisando a consulta, não haverá nenhum bloqueio ou bloqueio significativo e a consulta não trará de volta milhões de linhas de dados pela rede. A ferramenta de consulta simples significa que você não precisa se preocupar com o que o IIS pode ou não estar fazendo. Se não houver SQLCMD.EXE, OSQL.EXE ou ferramenta semelhante instalada no servidor IIS, pode valer a pena escrever um pequeno script psh ou vbs para testar a conectividade com o SQL Server. Se você não tiver esse tipo de acesso ao servidor IIS, provavelmente poderá escrever uma página ASP especial que apenas execute essa consulta simples e retorne o resultado e quanto tempo levou para ser executada.
Se eu tiver que adivinhar o problema, será este-> Especialmente com equipamentos e drivers mais antigos, evite confiar nas configurações de "negociação automática" nas NICs. Defina ambos os cartões com as mesmas configurações manualmente.
Eu sei que é uma chatice, mas eu pessoalmente vi isso resolver uma dúzia de problemas semelhantes em que o pessoal da rede ficou perplexo. (Afinal, esses são servidores e não é como se eles fossem conectados a vários switches diferentes e precisassem renegociar a velocidade do link ou as configurações duplex.)
Você também pode ver esse problema observando as taxas de dados nas NICs, medidas em MB/segundo, com o Monitor de desempenho. Depois de estabelecer uma linha de base, altere as configurações nas NICs e observe novamente.
Geralmente, você consegue alterar essas configurações "ao vivo", mas eu não tentaria fazer isso no horário de pico de carregamento na primeira vez que mexi nessas configurações. Uma avaliação em um ambiente de teste seria melhor, se você tiver um. Se você tiver uma janela de manutenção, seria melhor. Se houver apenas 1 NIC no servidor, tome cuidado para não configurar a NIC de forma que ela não possa se comunicar com o switch ou você poderá ter que pedir a alguém para fazer login fisicamente no console e isso será uma chatice para todos.
Responder2
Existem muitas razões possíveis. Pode ser um problema com um dos drivers do adaptador de rede, por exemplo.
Você terá que verificar se a conexão SQL é o gargalo ou se é um problema geral de rede. Tente emitir um comando "select getdate()" do servidor web para ver se todas as consultas são afetadas.
Os pings para o servidor de banco de dados também são lentos? Além disso, tente usar o endereço IP em vez do nome do servidor - talvez seja um problema de resolução de DNS.