El front-end web y la base de datos de mi sitio están separados en dos servidores, que están conectados por una LAN de 1000M.
Encuentro que el tiempo de respuesta de casi todas las consultas es de más de 800 ms. Puedo asegurarme de que todas mis consultas estén bien porque cuando las implemento en un solo servidor el problema no aparece.
sitio web/asp.net 2.0 base de datos/servidor sql 2000
Respuesta1
Si su DNS está provocando un retraso de 800 ms en (lo que debería ser) una dirección IP almacenada en caché, hay un problema grave con su configuración de red. EN MI HUMILDE OPINIÓN. Puedes ver si eso es un problema usando ping.
Utilice traceroute para asegurarse de que los paquetes utilicen una ruta eficiente entre las dos computadoras. Esto es fácil de hacer, por lo que vale la pena intentarlo antes de jugar con otras cosas. Si hay muchos saltos en la ruta, tal vez más de dos o tres, busque un encargado de la red y pregúntele por qué es así.
Al intentar solucionar problemas de red SQL, es mejor utilizar una consulta muy simple, como "SELECT GETDATE()", y utilizar una herramienta de consulta simple como SQLCMD.EXE. La consulta simple significa que el servidor no tendrá que dedicar mucho tiempo a analizar la consulta, no habrá ningún bloqueo o bloqueo significativo y la consulta no devolverá millones de filas de datos a través de la red. La sencilla herramienta de consulta significa que no tiene que preocuparse por lo que IIS podría estar haciendo o no. Si no hay SQLCMD.EXE, OSQL.EXE o una herramienta similar instalada en el servidor IIS, podría valer la pena escribir un pequeño script psh o vbs para probar la conectividad con SQL Server. Si no tiene ese tipo de acceso al servidor IIS, probablemente podría escribir una página ASP especial que simplemente ejecute esa consulta simple y devuelva el resultado y cuánto tiempo tardó en ejecutarse.
Si tengo que adivinar el problema, será este:> Especialmente con equipos y controladores más antiguos, evite confiar en la configuración de "negociación automática" de las NIC. Configure ambas tarjetas con la misma configuración manualmente.
Sé que es un fastidio, pero personalmente he visto que esto soluciona una docena de problemas similares en los que los chicos de la red estaban perplejos. (Estos son servidores, después de todo, y no es como si estuvieran conectados a muchos conmutadores diferentes y alguna vez necesitaran renegociar la velocidad del enlace o la configuración dúplex).
También puede ver este problema observando las velocidades de datos en las NIC, medidas en MB/segundo, con Performance Monitor. Una vez que haya establecido una línea de base, cambie la configuración de las NIC y observe nuevamente.
Por lo general, puedes salirte con la tuya cambiando esas configuraciones "en vivo", pero no lo intentaría en el momento de carga máxima la primera vez que jugueteé con esas configuraciones. Sería mejor una prueba en un entorno de prueba, si tiene uno. Si tiene una ventana de mantenimiento, sería lo mejor. Si solo hay 1 NIC en el servidor, tenga cuidado de no configurar la NIC de manera que no pueda comunicarse con el conmutador o podría tener que pedirle a alguien que inicie sesión físicamente en la consola y eso es un fastidio para todos.
Respuesta2
Hay muchas razones posibles. Podría ser un problema con uno de los controladores del adaptador de red, por ejemplo.
Tendrás que comprobar si la conexión SQL es el cuello de botella o si es un problema general de red. Intente emitir un comando "select getdate()" desde el servidor web para ver si todas las consultas se ven afectadas.
¿Los pings al servidor de la base de datos también son lentos? Además, intente utilizar la dirección IP en lugar del nombre del servidor; tal vez sea un problema de resolución de DNS.