Tenemos un conjunto de 5 sistemas de subastas en línea que se ejecutan en Windows Azure & 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.SQL Azure: más tiempos de espera intermitentes
El rol del trabajador es responsable del mantenimiento y ejecuta dos grupos de procesos. Un grupo se ejecuta cada diez segundos, el otro cada segundo. Cada proceso probablemente ejecutará una consulta de base de datos o un procedimiento almacenado. Estos están programados 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 métodos de controlador 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 ventanas de oficina abierta, y 25 ventanas de usuario final abiertas, todas golpeando el sistema repetidamente.
Durante mucho tiempo hemos estado experimentando errores intermitentes de tiempo de espera de SQL. Tres de los más comunes son:
System.Data.SqlClient.SqlException: A transport-level error has occurred when receiving results from the server. (provider: TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.)
System.Data.SqlClient.SqlException: A transport-level error has occurred when receiving results from the server. (provider: TCP Provider, error: 0 - The semaphore timeout period has expired.)
System.Data.SqlClient.SqlException: Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.
El único escenario predecible es durante una subasta donde un controlador específico -> sproc comienza a tiempo de espera durante el evento (presumiblemente debido a la carga). El resto de las veces los errores parecen ser completamente aleatorios y vienen en solteros, 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 métodos de administración, o quizás un usuario que haya iniciado sesión y haya visto su cuenta.
otra información:
he tratado de ejecutar los afectados consultas/sprocs en SQL Azure utilizando ambos SSMS locales y herramienta de consulta basada en la web Azure - todos parecen para ejecutar de forma rápida 1 segundo como máximo. Los planes de consulta no muestran nada demasiado sospechoso aunque de ninguna manera soy un experto SQL en rendimiento de consultas o cualquier otro tipo de experto J
Hemos envuelto todas las áreas afectadas en Azure SQL Transient Fault Handling Blocks, pero como está discutido aquí http://social.msdn.microsoft.com/Forums/en-US/ssdsgetstarted/thread/7a50985d-92c2-472f-9464-a6591efec4b3, no atrapan los tiempos de espera, y de acuerdo con "Valery M" esto es por una buena razón.
No estamos almacenando ninguna información de sesión en la base de datos, aunque la información de membresía asp.net se almacena en la base de datos.
Usamos 1 "instancia de servidor 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 tiempo, 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 servidor 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 servidor 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 de antemano.
Ilan
Ilan, estoy experimentando el mismo tipo de error en aplicaciones fuera en este momento. lo acabaste haciendo? Por cierto, en esa publicación de error transitorio, Valery M afirma que si el plan de ejecución y los índices de la base de datos se ven bien, entonces probablemente sea correcto usar el patrón para al menos algunos de los tiempos de espera que no puede resolver. –