Latenz zwischen Azure-Webrolle und SQL Azure- und Anwendungsleistung

Ich habe dies in einem anderen Thread gepostet, aber es ist alt und wurde geschlossen. Ich denke, dass es einige Ihrer Probleme hervorhebt.

Ich habe versucht, unsere Business-App in die Cloud zu verschieben. In Anbetracht der Tatsache, dass unsere Server vor Ort über 8 Jahre alt sind, sollte es bei den Azure-Diensten eine deutliche Verbesserung geben. Als wir jedoch unsere App testeten und die Cloud versus onsite verglichen, stellten wir fest, dass es in der Cloud fast dreimal so viel Latenz gab wie vor Ort (mehr als 8 Jahre alte Server) und 20% latenter, wenn man sie mit modernen Geräten vergleicht. Unsere App ist eine asp.net App und die DB ist etwa 11 GB groß.

SQL Azure und Leistung

1. Verwenden Sie niemals eine gepoolte Verbindung in der Cloud. Wenn Sie dies tun, werden Ihre Abfragen links und rechts zentriert. Öffnen Sie stattdessen eine Verbindung und halten Sie sie offen, bis Sie fertig sind.
2. Verwenden Sie das Zwischenspeichern. Sie haben keine Wahl, wenn Sie hoffen, dass dies funktioniert. Ich habe eine Website erfolgreich in der Cloud, aber ich musste Caching verwenden, um eine angemessene Leistung daraus zu machen.
3. Erkenne, dass es nicht deine Schuld ist! Das Azure-Team muss ihr Ende mehr beheben als Ihr eigenes. Wir haben eine schlanke App, wir haben zehn Jahre lang Upgrades, Optimierungen und Optimierungen durchgeführt, und wenn wir es nicht schaffen, werden Sie es auch nicht tun.

Ich mag Azure als Konzept. Ich mag die Optionen. Ich mag die Erweiterbarkeit, aber ich mag die Leistung nicht. Ich hoffe, dass Microsoft etwas mehr Aufmerksamkeit darauf verwendet und einige Änderungen vornimmt, da niemand sein Geschäft dorthin verlagern sollte, bis dies behoben wurde.

Tests

Tests werden ausgeführt, indem eine Reihe von Abfragen ausgeführt wird, die auf genau die gleichen Daten zugreifen und über eine benutzerdefinierte Funktion im Code ausgeführt werden, die die Antwortzeit von der Erstellung eines Objekts bis zur entsorgten Zeit misst (gezwungen, in die Datenbank zu schreiben) ). Dieses Objekt umschließt den Code, der getestet wird.

Es wurde kein Caching für den Test aktiviert, aber ich habe den Code und die DB bereits einmal ausgeführt und die besten Ergebnisse erzielt, so dass der DB-Server die Abfrage optimieren konnte und der Webserver die Baugruppen ordnungsgemäß laden konnte .

Test 1 - Web und DB auf demselben guten Rechner

• Quad-Core 2,5 GHz, 8 GB Ram @ 800Mhz mit 1300 FSB und SQL 2005
• ergibt 290 ms Antwortzeit.

Test 2 - Web und DB auf demselben Rechner

• SQL und Web auf 2 Proc (Dual-Core 3.0 GHz), 16 GB Ram @ 200Mhz mit 200 FSB und SQL 2005 Wirklich alter IBM Server.
• Web und SQL sind lokal zueinander
• ergibt 656 ms Antwortzeit.

Test 3 - Web getrennt von DB

• SQL auf 2 Proc (Dual-Core 3.0 GHz), 16 GB Ram @ 200Mhz mit 200 FSB und SQL 2005
• Web auf 1 Proc Dual-Core 3.0 GHz, 8 GB Ram @ 200Mhz mit 200 FSB
• Wirklich alter IBM Server.
• Web auf einer Maschine und SQL auf der anderen.
• ergibt 796 ms Antwortzeit.

Test 4 - Azure

• Mittlere VM auf Azure
• SQL Azure DB
• ergibt 3.174 ms Antwortzeit.

Schlussfolgerungen

• Der Unterschied in der Latenzzeit beim Wechsel von einem Szenario mit einem Server zu einem Szenario mit zwei Servern betrug 140 ms .
• Der Wechsel von diesem Szenario zu Azure war 2.518 ms . das ist 17,98 mal schlechter als auf meinen 8 Jahre alten Maschinen.

Tun Sie es nicht, bis sie das Problem behoben haben und nehmen Sie sich die Zeit, sie wissen zu lassen, dass es auch für Sie ein Problem ist.