Der beste Weg, um die Leistung zu verbessern (und irgendwie Failover)

Question

Wir haben eine Anwendung ausgeführt, wo IIS und SQL auf dem gleichen Computer sind. Es ist ein Windows2003-Standard-Server mit 4 GB RAM auf einer VM.

Jetzt steigt die Anzahl der Benutzer ständig. Es gibt auch einige riesige Statistiken, die von den Benutzern ausgeführt werden können, aber die Leistung für andere Benutzer sehr beeinflusst. Also müssen wir die Leistung irgendwie verbessern.

Ich dachte an die Trennung von IIS und SQL auf 2 verschiedenen Maschinen mit Windows2008 64bit und mindestens 6gigs RAM für jede Maschine, aber es sollte auch eine Failover-Lösung haben.

Können Sie einige Szenarien zur Lösung der Leistung und des Failover-Problems empfehlen?

Dank

ps:

Nur zur Info: Wir sind jetzt Statusverwaltung in IIS inproc, aber ich denke, es wird besser sein zu sqlstatemanagement zu ändern.

EDIT

Ich habe die Frage auf den Punkt der Failover erweitert. Da unser Kunde nicht zu viel Geld für Server- und SQL-Lizenzen ausgeben möchte. Wäre es "ok", nur eine Replikation zu einem zweiten SQL-Server durchzuführen und dies als Failover zu verwenden? Kennst du bessere "billige" Lösungen?

Die Anwendung ist nur für den internen Gebrauch, aber jetzt sind mehr und mehr Abteilungen in diesem Projekt beteiligt.

Answer 1

Sie Gerade jetzt 32 haben Bit OS auf der VM nehme ich an. Da die Standard Edition AWE die beiden Server (IIS und SQL) nicht erlaubt, lädt der SQL Server maximal 1,8 GB und hinterlässt viel RAM für IIS und OS. Aber sobald Sie zu 64-Bit-Betriebssystem wechseln, werden sich die Dinge ändern, da der SQL-Server den gesamten Arbeitsspeicher für seinen Pufferpool (~ 5 GB, wenn 6 GB verfügbar) verwendet und ihn dann an das Betriebssystem zurückgibt, wenn notified. Dieses Verhalten kann durch Konfigurieren von SQL Server memory options optimiert werden. Indem Sie IIS und SQL auf separate VMs aufteilen, belassen Sie den gesamten Speicher der SQL-VM für die Pufferpools, und das ist gut. Im Idealfall sollten Sie über ausreichend Arbeitsspeicher verfügen, damit SQL die gesamte (n) Datenbank (en) in den Arbeitsspeicher laden kann (einschließlich tempdb) und nur die Platte für Protokollschreibvorgänge berühren und die Datenbank (en) überprüfen muss. Mit anderen Worten bedeutet mehr RAM schnelleres SQL. Es ist bei weitem die wichtigste Hardware-Ressource, die SQL für die Leistung benötigt und den größten Gewinn für das Geld bringt.

Nun zurück zu der allgemeinen Frage zum 'Failover'. In SQL Server sind die Lösungen für high availability in zwei Kategorien unterteilt: automatische und Handbuch. Für automatische Failover haben Sie wirklich nur ein paar Lösungen:

• Clustering. Herkömmlicherweise ist dies aufgrund der hohen Kosten für die Hardware, die das Clustering unterstützt, ziemlich teuer, aber bei VMs ist dies eine andere Geschichte. Standard Edition SQL unterstützt zwei Knotencluster. Clustering ist ein wenig schwierig zu implementieren, aber es ist recht einfach zu bedienen und erfordert keine Anwendungsänderungen zu unterstützen. Beim Clustering der Failover-Einheit handelt es sich um eine gesamte SQL Server-Instanz (dh jede Datenbank, einschließlich master/tempdb/model und msdb, alle Logins, alle SQL-Agent-Jobs usw.). Ein Cluster ist nicht eine Performance-Lösung, da der Standby-Server gerade im Leerlauf ist, falls der Hauptserver abstürzt. Sie können die Bereitschafts-VM nutzen, indem Sie den sogenannten "Aktiv-Aktiv" -Cluster bereitstellen. Dies bedeutet, dass Sie zwei Cluster bereitstellen, von denen einer auf VM1 und der Standby-Modus auf VM2, der andere auf VM2 und der Standby-Modus auf VM1 aktiv ist. Im Falle eines Failovers muss eine der VMs die Last beide Instanzen nehmen, und deshalb sind Active-Active-Bereitstellungen manchmal verpönt. Angesichts der Tatsache, dass Sie planen, auf VMs zu implementieren, die nicht auf (teurem) Metall sind, würde ich dagegen empfehlen, da es keine großen Kosten für die Ammortisierung gibt.
• Mirroring. Dies wird einen Hot-Standby-Spiegel Ihrer Datenbank (keine Instanz) halten. Die Spiegelung wird wegen der geringeren Implementierungskosten (keine spezielle Hardware), der geringeren Failoverzeit (Sekunden im Gegensatz zu Minuten in Clustering) und der Geoverteilungsfunktionen (Spiegelung unterstützt die Verteilung von Knoten auf separaten Containets, Clusterunterstützung unterstützt nur eine geringe Entfernung von wenigen) dem Clustering vorgezogen hundert Meter zwischen Knoten). Da die Failover-Einheit jedoch eine Datenbank ist, bietet die Spiegelung nicht die einfache Verwendung von Clustering. Viele der Ressourcen, die von einer Anwendung benötigt werden, befinden sich in der Datenbank nicht: Logins, Agent-Jobs, Wartungspläne, Datenbank-E-Mail-Nachrichten und so weiter und so fort. Da nur die Datenbank fehlschlägt, muss das Failover sorgfältig geplant werden, damit die Anwendung nach dem Failover weiter funktioniert (z. B. Logins müssen übertragen werden).Die Anwendung muss außerdem die Spiegelungsbereitstellung kennen, so dass sie connects properly. Mit der Standard Edition können Sie die Spiegelung nur in high-safety mode bereitstellen.
• Hardware Spiegelung. Ich werde hier nicht näher darauf eingehen, es erfordert spezialisierte SAN-Hardware, die Spiegelung auf Festplattenebene ermöglicht.

Wenn Sie die manuelle Failover-Lösungen erwägen, dann gibt es einige weitere Alternativen:

• Log Shipping. Der Protokollversand ist im Wesentlichen eine Out-of-Band-Spiegelung. Anstatt Protokolldatensätze in Echtzeit über eine dedizierte TCP-Verbindung zu übertragen, wird das Protokoll über Dateikopiervorgänge übertragen. Es gibt nur wenige Gründe, den Protokollversand über die Spiegelung zu wählen: Die Stand-by-Datenbank kann für die Berichterstellung abgefragt werden, der Stand-by kann sich an einem Ort mit sporadischer Konnektivität befinden, der Stand-by kann mit einer wirklich leistungsschwachen Maschine untergebracht werden .

• Replikation. Dies ist wirklich keine Hochverfügbarkeitslösung. Replikation ist eine Lösung zum Bereitstellen von Datenkopien und/oder zum Austausch von Datenaktualisierungen zwischen Sites. Während es verwendet werden kann, um eine Art von hochverfügbarer "Schicht" -Lösung zu implementieren, gibt es viele Probleme damit und grundsätzlich keinen Vorteil. Im Vergleich zu sowohl Protokollversand und Spiegelung, hat es eine Anzahl von zusätzliche Nachteile, weil die Einheit der Failover nicht einmal eine Datenbank ist, ist nur Schichten von Daten innerhalb einer Datenbank (einige der Tabellen). Metadaten wie Benutzer- und Sicherheitsberechtigungen werden nicht überschrieben, Schemaänderungen müssen in einem replication aware mode vorgenommen werden und einige Änderungen können nicht einmal repliziert werden. Vertragsgemäß bieten sowohl die Spiegelung als auch der Protokollversand eine Stand-by-Kopie, die identisch mit der Produktionsdatenbank ist, die automatisch die an der Datenbank vorgenommene Änderung abdeckt.

Sie erwähnen, dass Sie Lizenzkosten betroffen sind: Sie brauchen eigentlich keine Lizenz für eine der passive Server mit jeder dieser Technologien außer Replikation. Die Standby-Server benötigen nur dann eine Lizenz, wenn sie aktiv werden und die Datenbank länger als 30 Tage laufen.

Wenn Sie planen, auf VMs bereitzustellen, wäre meine Wahl Clustering. Wenn Sie auf Metall bereitstellen würden, würde ich stattdessen Spiegelung aufgrund der Kosten für Clustering-Hardware empfehlen.

Answer 2

SQL Server funktioniert immer am besten, wenn es das "NUR" ist, das auf einer Maschine ausgeführt wird. Sie werden schnell, einfach und gut davon profitieren. Es scheint, die Kontrolle über alles zu übernehmen und ist immer glücklicher, wenn es kann :)

Answer 3

Es klingt wie Sie wirklich fragen, sollten Sie die DB auf eine separate Maschine setzen. Dies verbessert möglicherweise nicht die Leistung (wird aber mit zunehmender Latenzzeit abnehmen), verbessert aber die Skalierbarkeit (was ich vermute, ist das, was Sie wirklich brauchen).

Leistung <> Skalierbarkeit.

Jedoch kommen mehr Probleme ins Spiel - wenn Sie nicht genug RAM-Leistung haben, kann die DB auf der gleichen Box abnehmen - SQL Server mag RAM zu verwenden.

Deshalb empfiehlt Microsoft für Dinge wie TFS, die SQL-Server verwenden, für eine geringe Anzahl von Benutzern, dass es auf einem Computer installiert ist, aber für eine höhere Anzahl von Benutzern empfiehlt Microsoft die Datenbank auf einem anderen Server.

Sie können read about the deployment options for TFS here.

Durch die Umstellung der SQL Server-Statusverwaltung wird die Leistung nicht erhöht. Dies wird wahrscheinlich verringert, Sie erhalten jedoch weitere Vorteile (wie Zuverlässigkeit).

Es klingt wie Sie müssen tatsächlich herausfinden, was der Leistungsengpass zuerst ist. Nach meiner Erfahrung ist dies in der Regel in der DB.

Haben Sie Standard-ASP.NET-Optimierungstechniken wie Caching untersucht? Microsoft bietet guidance on application tuning, die auch für Sie nützlich sein könnten.

Wenn Sie SQL Server in einem Webanwendungsszenario verwenden und möglicherweise SQL Server 2005 oder höher verwenden, möchten Sie möglicherweise über Snapshot isolation lesen. Manchmal ist dies nicht der Grund für Leistungsprobleme in Webanwendungen.

Answer 4

Die Trennung der Schichten kann helfen. Oft ist das Tuning einer Maschine für eine DB ziemlich spezifisch, also ist das ein vernünftiger erster Versuch.

Wenn Sie jedoch zwei Arten von Benutzeraktivitäten haben, von denen eine sehr schwer ist, dann werden Sie immer das Risiko eingehen, dass ein paar schwere Benutzer den Rest der Bevölkerung verletzen.

Zwei Dinge, die Sie betrachten können:

1. Können Sie ein "Datawarehouse" Ansatz verfolgen? Lassen Sie eine zweite DB von Anfang an tröpfeln. Die neue DB ist da, wo die Heavy User ihre Arbeit machen. Sicher werden ihre Statistiken etwas veraltet sein, aber das wird konzeptuell immer wahr sein - wenn sie sich die Antworten anschauen, wird sich die Welt bewegt haben.
2. Steuern Sie die Anzahl der Stats-Anfragen, die Sie zu einem bestimmten Zeitpunkt zulassen. Vielleicht haben sie sie als "Job" in einer Warteschlange eingereicht. Führen Sie sie als niedrige Priorität aus.

Answer 5

Sie diesen Artikel 2 auf Codeproject für ASP.Net Performance-Tuning

1. http://www.codeproject.com/KB/aspnet/10ASPNetPerformance.aspx
2. http://www.codeproject.com/KB/aspnet/aspnetPerformance.aspx

ich persönlich umgesetzt haben, diese Techniken in meinem asp.net verweisen Apps und erzielte mehr als 30% Leistungsverbesserungen.

Zusätzlich können Sie zu this Artikel zu 99,99% für Ihre Anwendung finden.

3. http://www.codeproject.com/KB/aspnet/ProdArch.aspx

Answer 6

Naturally IIS Trennen und SQL-Server ist der erste Schritt. Sql Server möchte wirklich eine komplette Maschine für sich haben.

Die zweite Sache, die wichtig ist, um die Anwendung zu analysieren, wie es läuft. Versuchen Sie niemals, die Leistung Ihrer Anwendung zu optimieren, ohne reale Nutzungsdaten, weil Sie wahrscheinlich nur Zeit damit verbringen, Dinge zu optimieren, die selten aufgerufen wird. Eine Technik, die ich mit Erfolg in der Vergangenheit verwendet haben, ist eine System.Diagnostics.Stopwatch in Request_Begin in der global.asax zu erstellen, dann speichern Sie es in einem Kontextvariable

var sw = new Stopwatch(); 
sw.Start() 
HttpContext.Current.Items["stopwatch"] = sw; 

In Request_End, die Stoppuhr agin erhalten

sw = HttpContext.Current.Items["stopwatch"]; 
sw.Stop(); 
Timespan ts = sw.Elapsed; 

Und dann in eine Protokolltabelle schreiben, wie lange es dauerte, die Anforderung zu verarbeiten. Protokollieren Sie auch die URL (sowohl mit als auch ohne Abfrage-String-Parameter) und alle möglichen Dinge, die Ihnen helfen, die Leistung zu analysieren.

Dann können Sie Ihre Anwendung analysieren und finden, welche Operationen am längsten dauern, die am häufigsten genannt werden usw. Das wird Ihnen erlauben zu sehen, ob es eine Seite gibt, die viel angefordert wird, und es dauert im Allgemeinen sehr lange Zeit zu vervollständigen, das sollte ein Ziel der Optimierung sein, mit welchen Tools Sie dafür haben, sowohl .NET-und SQL-Profiler.

Andere Dinge, die ich auch normalerweise loggen, sind IP-Adressen und Benutzer-ID für angemeldete Benutzer. Das gibt mir auch ein unschätzbares Debugging-Tool, wenn Fehler auftreten.

Ein Grund, warum es in einer Tabelle zu setzen, ist es im Gegensatz zu einer Protokolldatei zu schreiben, dass Sie SQL-Syntax, Gruppe heraus filtern können, die durchschnittliche Zeit berechnen usw.