Das Web-Frontend und die Datenbank meiner Site sind auf zwei Servern verteilt, die über ein 1000-M-LAN verbunden sind.
Ich stelle fest, dass die Antwortzeit für fast jede Abfrage mehr als 800 ms beträgt. Ich kann sicherstellen, dass alle meine Abfragen in Ordnung sind, da das Problem nicht auftritt, wenn ich sie auf einem einzelnen Server bereitstelle.
Website/ASP.NET 2.0-Datenbank/SQL Server 2000
Antwort1
Wenn Ihr DNS eine Verzögerung von 800 ms zu einer (eigentlich) zwischengespeicherten IP-Adresse verursacht, stimmt etwas mit Ihrer Netzwerkkonfiguration nicht. Meiner bescheidenen Meinung nach. Mithilfe eines Pings können Sie feststellen, ob dies ein Problem ist.
Verwenden Sie Traceroute, um sicherzustellen, dass die Pakete eine effiziente Route zwischen den beiden Computern verwenden. Dies ist einfach durchzuführen, es lohnt sich also, es auszuprobieren, bevor Sie mit anderen Dingen herumspielen. Wenn die Route viele Hops enthält, vielleicht mehr als zwei oder drei, suchen Sie einen Netzwerkexperten auf und fragen Sie ihn, warum das so ist.
Bei der Behebung von SQL-Netzwerkproblemen empfiehlt es sich, eine sehr einfache Abfrage wie „SELECT GETDATE()“ und ein einfaches Abfragetool wie SQLCMD.EXE zu verwenden. Die einfache Abfrage bedeutet, dass der Server nicht viel Zeit mit der Analyse der Abfrage verbringen muss, es zu keinen nennenswerten Sperren oder Blockierungen kommt und die Abfrage nicht Millionen von Datenzeilen über das Netzwerk zurückgibt. Das einfache Abfragetool bedeutet, dass Sie sich keine Gedanken darüber machen müssen, was IIS möglicherweise tut oder nicht tut. Wenn auf dem IIS-Server kein SQLCMD.EXE, OSQL.EXE oder ein ähnliches Tool installiert ist, lohnt es sich möglicherweise, ein kleines PSH- oder VBS-Skript zu schreiben, um die Verbindung zum SQL-Server zu testen. Wenn Sie keinen derartigen Zugriff auf den IIS-Server haben, können Sie wahrscheinlich eine spezielle ASP-Seite schreiben, die diese einfache Abfrage ausführt und das Ergebnis sowie die Ausführungsdauer zurückgibt.
Wenn ich das Problem erraten müsste, wäre es das Folgende: Verlassen Sie sich insbesondere bei älteren Geräten und Treibern nicht auf die „Auto-Negotiation“-Einstellungen der Netzwerkkarten. Stellen Sie beide Karten manuell auf die gleichen Einstellungen ein.
Ich weiß, dass es mühsam ist, aber ich habe persönlich gesehen, wie dies etwa ein Dutzend ähnlicher Probleme gelöst hat, bei denen die Netzwerkleute nicht weiterkamen. (Dies sind schließlich Server, und es ist nicht so, dass sie an viele verschiedene Switches angeschlossen sind und jemals die Verbindungsgeschwindigkeit oder Duplexeinstellungen neu aushandeln müssten.)
Sie können dieses Problem auch erkennen, indem Sie die Datenraten auf den Netzwerkkarten (gemessen in MB/Sekunde) mit dem Leistungsmonitor beobachten. Sobald Sie eine Basislinie festgelegt haben, ändern Sie die Einstellungen auf den Netzwerkkarten und beobachten Sie erneut.
Normalerweise können Sie diese Einstellungen „live“ ändern, aber ich würde es nicht zu Spitzenlastzeiten versuchen, wenn ich das erste Mal an diesen Einstellungen herumgefummelt habe. Ein Versuch in einer Testumgebung wäre besser, falls Sie eine haben. Wenn Sie ein Wartungsfenster haben, wäre das am besten. Wenn der Server nur eine Netzwerkkarte hat, achten Sie darauf, die Netzwerkkarte nicht so einzustellen, dass sie nicht mit dem Switch kommunizieren kann, da Sie sonst möglicherweise jemanden bitten müssen, sich physisch bei der Konsole anzumelden, und das ist für alle ein Mist.
Antwort2
Dafür gibt es viele mögliche Gründe. Es könnte zum Beispiel ein Problem mit einem der Netzwerkadaptertreiber sein.
Sie müssen prüfen, ob die SQL-Verbindung der Engpass ist oder ob es sich um ein allgemeines Netzwerkproblem handelt. Versuchen Sie, vom Webserver aus den Befehl „select getdate()“ einzugeben, um zu sehen, ob alle Abfragen betroffen sind.
Sind die Pings zum Datenbankserver auch langsam? Versuchen Sie außerdem, die IP-Adresse anstelle des Servernamens zu verwenden – möglicherweise liegt ein DNS-Auflösungsproblem vor.