Jan Welker

Bei einer Webanwendung, dich gerade in ASP.NET entwickle, bin ich vor kurzem auf eine große Anzahl von Verbindungsproblemen zwischen Windows Azure (IIS) und SQL Azure gestoßen.

Die Webseite nutzt Windows Azure, AppFabric-Cache und SQL Azure. Alles lag im Rechenzentrum West-Europa.

Wie haben sich die Probleme geäußert und wann sind sie aufgetreten?

Beim Datenbankzugriff mit dem Entity Framework gab es folgende Exceptions:

• Invalid attempt to read when no data is present.
• The underlying provider failed on Open.
• Calling 'Read' when the data reader is closed is not a valid operation.
• An error occurred while reading from the store provider's data reader.
• A connection was successfully established with the server, but then an error occurred during the pre-login handshake. (provider: TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.)
• A transport-level error has occurred when receiving results from the server. (provider: TCP Provider, error: 0 - The semaphore timeout period has expired.)

Die Fehler sind sind aufgetreten, sobald die Webseite etwas stärker belastet wurde. Dies geschah immer dann, wenn die Webseite durch einen Bot (z.B. Google oder Bing) gecrawlt wurde. Eigentlich sollten solche geringen Lastschwankungen Windows Azure bzw. SQL Azure nicht weiter beeindrucken - dachte ich.

Mein erster Versuch die Fehler zu beheben, war die Größe der VM Instanz zu erhöhen. Leider brachte dies keine Besserung.
An meinem Code konnten diese Fehler nicht liegen, da die Webseite vor dem Umzug zu Azure schon einige Monate auf meinem eigenen Server fehlerfrei lief.
Ich schilderte diese Probleme dem Azure Support und war von der Antwort sehr überrascht. Der Support wusste von dem Problem und hatte auch einen Namen dafür parat: “Transient Conditions”. Ich wurde auf einen Artikel vom “Windows Azure Customer Advisory Team” hingewiesen, in dem folgendes zu lesen ist:

The database connections may also be dropped due to the variety of reasons related to network connectivity between the client and distant Microsoft data centers: quality of network, intermittent network faults in the client’s LAN or WAN infrastructure and other transient technical reasons.

Als Lösung wird der Einsatz des so genannten Transient Fault Handling Framework vorgeschlagen, das im wesentlichen nichts weiter macht, als den Datenbankzugriff zu überwachen. Im Fehlerfall wird der Datenbankzugriff einfach erneut versucht.

Ich habe mich aus mehreren Gründen gegen den Einsatz dieses Frameworks entschieden:

• das Framework ist riesengroß und hat einige Abhängigkeiten
• es ist schlecht dokumentiert
• ich sehe nicht ein, Infrastruktur-Fehler im Code auszugleichen, wodurch die Ladegeschwindigkeit der Webseite sinken würde

Gerade zum letzten Punkt, der Performance, habe ich einige Versuche gemacht.
30 bis 50 Versuche um Daten zu lesen waren im Fehlerfall keine Seltenheit und das, obwohl Datenbank und IIS im selben Azure – Rechenzentrum (West-Europa) lagen. Die Performance der Webseite würde mit dieser Strategie deutlich in die Knie gehen.

Als nächstes habe ich versucht herauszufinden, ob man die Verbindungsprobleme nicht anders in den Griff bekommen kann.
Ich habe die Webseite wieder auf meinem eigenen Webserver gelegt, aber die Datenbank bei Azure gelassen, schon waren die Fehler weg!

Auch wenn die Webseite im Rechenzentrum Europa Nord liegt und die Datenbank in Europa West, gibt es keine Probleme. In dieser Konstellation läuft die Webseite jetzt einen Monat fehlerfrei.

Bin ich mit meinen Erfahrungen ein Einzelfall (Ich habe ja öfter mal Pech mit Server-Hardware), oder hat Microsoft hier noch massive Probleme?