Temos um conjunto de 5 sistemas de leilão on-line em execução no Windows Azure e no SQL Azure. Cada sistema consiste em um único trabalhador da Web e uma ou mais funções da web. Cada sistema está usando ASP.NET MVC 3 e Entity Framework, Repository Pattern e StructureMap.

A função de trabalhador é responsável pelo serviço de limpeza e executa dois grupos de processos. Um grupo é executado a cada dez segundos, o outro a cada segundo. Cada processo provavelmente executará uma consulta de banco de dados ou um procedimento armazenado. Estes estão agendados com Quartz.net

A função da Web serve a interface pública e o back office. Entre outras funcionalidades crud básicas, ambas fornecem telas que, quando abertas, irão chamar repetidamente métodos do controlador que resultarão na execução de consultas somente leitura do procedimento armazenado. A frequência de repetição é de cerca de 2-3 segundos por cliente. Um caso de uso típico seria abrir 5 janelas de back office e abrir 25 janelas de usuário final - todas atingindo o sistema repetidamente.

Durante muito tempo, passamos por erros intermitentes de tempo limite de SQL. Três dos mais comuns são:

System.Data.SqlClient.SqlException: Ocorreu um erro de nível de transporte ao receber resultados do servidor. (provedor: TCP Provider, erro: 0 - Uma conexão existente foi forçosamente fechada pelo host remoto.)

System.Data.SqlClient.SqlException: Ocorreu um erro de nível de transporte ao receber resultados do servidor. (provedor: TCP Provider, error: 0 - O período de tempo limite do semáforo expirou.)

System.Data.SqlClient.SqlException: o tempo limite expirou. O período de tempo limite decorrido antes da conclusão da operação ou o servidor não está respondendo.

O único cenário previsível é durante um leilão em que um controlador específico -> sproc inicia o tempo limite durante o evento (presumivelmente devido à carga). Todas as outras vezes, os erros parecem ser completamente aleatórios e vêm em singles, dois e três etc., mesmo durante períodos de inatividade do usuário. Por exemplo, o sistema terá 18 horas sem erro e, em seguida, poderá haver de 5 a 10 erros de diferentes métodos de manutenção, ou talvez um usuário tenha efetuado logon e visualizado sua conta.

Outras informações:

Eu tentei executar as consultas / sprocs afetadas no SQL Azure usando o SSMS local e a ferramenta de consulta baseada na Web do Azure - todas parecem ser executadas rapidamente, 1 segundo no máximo. O Query planeja não mostrar nada de muito suspeito, embora eu não seja de forma alguma um especialista em desempenho de consulta SQL ou qualquer outro tipo de especialista para esse assunto.

Envolvemos todas as áreas afetadas nos Blocos de Tratamento de Falhas Transitórias do SQL do Azure - mas, como é discutido aquihttp://social.msdn.microsoft.com/Forums/pt-BR/ssdsgetstarted/thread/7a50985d-92c2-472f-9464-a6591efec4b3, eles não pegam timeouts, e de acordo com "Valery M" isso é por um bom motivo.

Não estamos armazenando nenhuma informação de sessão no banco de dados, embora as informações de associação do asp.net sejam armazenadas no banco de dados.

Usamos 1 "instância do servidor do SQL Azure", que hospeda todos os 5 bancos de dados, dois para preparação e três para produção. Todos os 5 sistemas são geralmente ativos ao mesmo tempo, embora seja improvável que mais de um esteja em uso de carga ao vivo a qualquer momento. Todas as funções da Web, funções de trabalho e o servidor do SQL Azure residem na mesma região geográfica do Azure.

Alguma idéia de onde deveríamos estar procurando? Ajudaria a dar a cada sistema seu próprio servidor SQL Azure? ... Falhar em uma solução por conta própria - é possível fazer com que a Microsoft abra um ticket de suporte e dê uma olhada no que está acontecendo com o nosso aplicativo - como se faz isso?

Desde já, obrigado.

Ilan