SQL Azure: más times de espera intermitentes

Tenemos un set de 5 sistemas de subastas en línea que se ejecutan en Windows Azure y SQL Azure. Cada sistema consta de un solo trabajador web y uno o más roles web. Cada sistema utiliza ASP.NET MVC 3 y Entity Framework, Repository Pattern y StructureMap.

El rol del trabajador es responsable del mantenimiento y ejecuta dos grupos de processs. Un grupo se ejecuta cada diez segundos, el otro cada segundo. Cada process probablemente ejecutará una consulta de database o un procedimiento almacenado. Estos están progtwigdos con Quartz.net

El rol web sirve a la interfaz pública y administrativa. Entre otras funcionalidades crud básicas, ambas proporcionan pantallas que, cuando están abiertas, invocarán repetidamente methods de controller que darán como resultado la ejecución de consultas de solo lectura de procedimiento almacenado. La frecuencia de repetición es de aproximadamente 2-3 segundos por cliente. Un caso típico de uso sería 5 windows de oficina abierta, y 25 windows de usuario final abiertas, todas golpeando el sistema repetidamente.

Durante mucho time hemos estado experimentando errores intermitentes de time de espera de SQL. Tres de los más comunes son:

System.Data.SqlClient.SqlException: se ha producido un error de nivel de transporte al recibir los resultados del server. (provider: TCP Provider, error: 0 – Una connection existente fue cerrada a la fuerza por el host remoto.)

System.Data.SqlClient.SqlException: se ha producido un error de nivel de transporte al recibir los resultados del server. (provider: TCP Provider, error: 0 – El período de time de espera del semáforo ha expirado).

System.Data.SqlClient.SqlException: el time de espera expiró. El período de time de espera transcurrido antes de la finalización de la operación o el server no responde.

El único escenario pnetworkingecible es durante una subasta en la que un controller específico -> sproc comienza a agotar el time de espera durante el evento (presumiblemente debido a la carga). El rest de las veces los errores parecen ser completamente aleatorios y vienen en singles, dos y tres, etc. incluso durante períodos de inactividad del usuario. Por ejemplo, el sistema pasará 18 horas sin un error y luego podría haber 5 – 10 errores de diferentes methods de administración, o quizás un usuario que haya iniciado session y haya visto su count.

Otra información:

He intentado ejecutar las consultas / sprocs afectados en SQL Azure utilizando SSMS local y la herramienta de consulta basada en la web de Azure: todas parecen ejecutarse rápidamente, 1 segundo como máximo. Los planes de consulta no muestran nada demasiado sospechoso, aunque de ninguna manera soy un experto en el performance de las consultas SQL, o cualquier otro tipo de experto para el caso J

Hemos envuelto todas las áreas afectadas en los bloques de administración de fallas transitorias SQL de Azure, pero como se describe aquí http://social.msdn.microsoft.com/Forums/en-US/ssdsgetstarted/thread/7a50985d-92c2-472f-9464-a6591efec4b3 , no atrapan times de espera, y de acuerdo con "Valery M" esto es por una buena razón.

No estamos almacenando ninguna información de session en la database, aunque la información de membresía de asp.net se almacena en la database.

Usamos 1 "instancia de server SQL Azure" que aloja las 5 bases de datos, dos para la puesta en escena y tres para la producción. Los 5 sistemas generalmente están activos al mismo time, aunque es poco probable que más de uno esté en estado de carga viva en un momento dado. Todos los roles web, los roles de los trabajadores y el server SQL Azure residen en la misma región geográfica de Azure.

¿Alguna idea de dónde deberíamos estar mirando? ¿Ayudaría darle a cada sistema su propio server SQL Azure? … Fallar una solución nosotros mismos – ¿es posible hacer que Microsoft abra un ticket de soporte y echar un vistazo bajo el capó de lo que está pasando con nuestra aplicación? ¿Cómo se puede hacer esto?

Gracias por adelantado.

Ilan

SQL Azure es un sistema multiusuario y usted podría estar sufriendo un potencial uso excesivo de otros inquilinos. Microsoft hace un buen trabajo al mantener a otros inquilinos acelerados, pero de vez en cuando las consultas de SQL Azure tienen time de espera.

Para abrir la compatibilidad con Microsoft, visite esta página: https://support.microsoft.com/oas/default.aspx?gprid=14919&st=1&wfxnetworkingirect=1&sd=gn