.NET-Leistungstipps für Enterprise-Webanwendungen

Die Punkte in der Frage sind Mikro-Optimierungen. Ich stimme der Prämisse zu, dass "jedes kleine bisschen hilft" - besonders wenn es auf Kosten der Lesbarkeit geht.

Wenn Sie Ihren Code wirklich leicht lesen und verstehen können, bedeutet das, dass Sie leicht architektonische Änderungen vornehmen können. Das sind die wirklich großen Gewinne, nicht die Mikrooptimierung. Je mehr Sie versuchen, den Code aus jeder Codezeile zu optimieren, desto schwieriger wird es, das gesamte Design zu refaktorisieren.

Also meine Tipps sind:

• Schreiben Sie den lesbarsten Code, den Sie können
• Optimieren Sie die Implementierung nicht zu früh - denken Sie jedoch frühzeitig an Architektur Leistungsprobleme
• Nehmen Sie keine Änderungen am Namen der Leistung vor, bis Sie über feste Zahlen verfügen, mit denen Sie feststellen können, ob Sie etwas verbessern
• Verwenden Sie einen Profiler, um Engpässe zu erkennen

Dies ist bisher nicht spezifisch für Web-Apps. Für Web-Apps (und serverseitig im Allgemeinen):

• Wenn Sie nicht wirklich wissen, dass Sie nie mehr als einen Server benötigen, stellen Sie sicher, dass der Code horizontal skaliert werden kann. Wenn Sie es sich leisten können, starten mit zwei Servern (oder mehr), damit Sie Probleme (Sitzungen usw.) frühzeitig ausbügeln können. Dies hilft auch beim Upgraden von Upgrades.

EDIT: Ich habe die Datenbank überhaupt nicht angesprochen. Kyles Antwort ist an dieser Front gut. Stellen Sie sicher, dass Ihre Datenbank auch skaliert werden kann, wenn möglich:)

Die größten Vorteile, die Sie in (fast) jeder Anwendung sehen werden, ist die Optimierung Ihrer Datenbank.

Kodierung ...

• Wählen Sie ein Dutzend Spalten aus, wenn Sie nur zwei brauchen?
• Ergreifen Sie alle Ergebnisse, um eine SUMME durchzuführen?
• Ergreifen Sie 1000 Datensätze, um 10 anzuzeigen?
• Feuern Sie hundert Abfragen auf jeder Seite ab?

Datenbank ...

• Haben Sie Indizes für Ihre Tabellen?
• Sind das die richtigen Indizes?
• Haben Sie einige Beispielabfragen mit SQL Profiler gepackt und ihre Ausführungspläne in Query Analyzer ausgecheckt?
• Sehen Sie TABLE SCAN - BAD!
• Sehen Sie INDEX SEEK - GUT!

Und wenn alles andere fehlschlägt, cache die Scheiße daraus und wirf mehr Hardware auf das Problem! :)

Wir gehen jeden Tag damit um.

Wir cachen einige Datensätze, die verwendet werden. Wir haben einen ziemlich komplexen Caching-Mechanismus für Datenschichten, der für uns gut funktioniert.

Faule Bewertung für fast alles.

Seiten- und partielles Caching für Benutzersteuerelemente

Wir verwenden den Sitzungszustand überhaupt nicht, also haben wir ihn komplett deaktiviert.

Konfigurieren Sie Websites so, dass sie als bekannter Benutzer mit niedriger Priorität ausgeführt werden.

Stellen Sie eine Verbindung zu SQL Server als derselbe Benutzer mit niedriger Priorität her. Dies hilft beim Verbindungs-Pooling - alle Verbindungen sind im Wesentlichen die gleichen.

KEINE Ad-hoc-SQL. Stored Procs NUR. Hilft mit performand UND SQL-Injektion.

string.Concat () anstelle von String + String + ... oder StringBuilder

Außer Manwood hat niemand ViewState erwähnt und es ist ziemlich überraschend. Ich würde ViewState Management als die wichtigsten Faktoren für die Leistungsverbesserung wählen.

Meine Liste:

1. View-Status aggressiv verwalten
2. UpdatePanel ist böse;) Machen Sie Juridicious
3. Nutzen Sie JavaScript-Frameworks wie jQuery
4. Beobachten Sie Ihre Server-Roundtrips
5. Verwenden Sie Async-Seiten für IO-gebundene Operationen
6. Ebenso wichtig ist das Caching auf verschiedenen Ebenen (Page level, data etc.)
7. Mit Ajax Daten "on demand" abrufen und lokal als XML zwischenspeichern (XML Dateninseln etc.)
8. Betrachten Sie die asynchrone Verarbeitung für lange laufende Operationen (Sie können entweder datenbankbasierte Jobwarteschlangen verwenden und sie über einen Windows-Dienst verarbeiten lassen. Eine AJAX-Anforderung könnte die Zeile zur Fertigstellung überwachen und die Benutzeroberfläche mit Sprechblasen aktualisieren)

Bearbeiten: [hinzugefügt 6-8]

Microsoft hat ein Buch mit dem Titel veröffentlicht Verbesserung der .NET-Anwendungsleistung und Skalierbarkeit Dies ist ein Muss Buch lesen.

Abgesehen von der Datenbank ist noch eine sehr wichtige Sache zu sehen ...

Seitengröße und Anzahl der Anfragen Dies sollte selbstverständlich sein, aber ASP.NET ist notorisch schlecht darin, Ihre Seiten mit einer Menge Mistausgabe zu füllen (die Größe nach oben zu treiben) und eine Million externer Skriptdateien (Anzahl von Anfragen) zu erstellen.

• Datenbank so wenig wie möglich zugreifen
• greifen Sie so wenig wie möglich auf web.config
zu
• wie manwood sagt, benutze den Cache gut. Ich könnte auch vorschlagen, diesen sehr guten Artikel über den Kernel zu lesen Modus-Caching
• Vermeiden Sie das Sperren, wenn Sie können
• einige Dinge (wie das Sortieren von Daten) können clientseitig heute durchgeführt werden (siehe Jquery)
• hier ist ein guter Artikel zum Lesen

• Posten Sie so selten wie möglich zurück. Verwenden Sie DHTML & amp; JavaScript, um die Seite zu manipulieren, wenn Benutzer komplexe Kriterien auswählen. Veröffentlichen Sie keine Änderungen an einer Seite als Reaktion auf jede kleine Benutzereinstellung.
• Verwenden Sie ASP.NET-Steuerelemente so sparsam wie möglich. Verwenden Sie so viel wie möglich HTML. Alle ASP.NET-Steuerelemente verursachen aufgrund des Ansichts- und Steuerungsstatus Kosten. Plain HTML hat diesen Overhead nicht. Ich habe einmal eine Web-App für Citibank gemacht, die aus einer Hauptabfrageseite bestand. Diese Seite war mäßig komplex. Es hatte nur ein ASP.NET-Steuerelement darauf. Es war eine Schaltfläche, die zur Erstellung eines benutzerdefinierten Excel-Arbeitsblatts mit benutzerdefinierten Daten zurückversetzt wurde.
• Verwenden Sie das MVC-Framework anstelle von ASP.NET. Viewstate und Control State sind außerhalb des Bildes, wenn Sie Brail oder NVelocity verwenden.
• Run Ants Profiler von Redgate-Software auf Ihrem Back-End-Code. Stellen Sie sicher, dass Ihr Postback-Event so kurz und bündig wie möglich ist.
• Wenn eine Seite Daten aus einer Tabelle abruft, die einmal alle 24 Stunden oder einmal pro Woche aktualisiert wird, schreiben Sie keine comon ASP.NET-Seite, um die Daten jedes Mal abzufragen, wenn ein Benutzer eine Anfrage stellt. Wenn die Daten statisch sind, sollten Sie auch die Seite statisch machen. Sie können statische Seiten auf NT-Scheduler-Basis mit XML-Literalen & amp; Linq zu XML-Klassen. Das ist die größte Geschwindigkeit, die ich dir geben kann.

• Nutzen Sie das Cache-Objekt für alle Daten, die sich nicht sehr oft ändern, aber häufig verwendet werden. Wenn Sie Ihre Cache-Objekte in Übereinstimmung mit Ihrer Datenbank halten müssen, sehen Sie sich SqlCacheDependency an.
• Deaktivieren Sie ViewState, wo es nicht erforderlich ist

Überprüfen Sie das Protokoll und minimieren Sie die Menge an HTML, die pro Anfrage geliefert wird. Viewstate und aufgeblähte Kontrollen von Drittanbietern können Ihre Anwendung ruinieren. Zum Beispiel verwendeten wir lange Zeit das Gitter von Infragistics. sehr sehr fähig, aber sogar in seiner entkleideten Form hat es Seiten von ca. 60-90k + viel Java-Script gemacht. Dies schränkte die Anzahl der Anfragen, die wir auch bei einer internen Gigabit-Verbindung ausführen konnten, stark ein.

Nach meiner Erfahrung machen die folgenden Dinge einen großen Unterschied:

• Verwenden Sie SQL Server Profiler, um langsam laufende Abfragen zu identifizieren. Verwenden Sie insbesondere die Optimierungsvorlage, um zu sehen, ob Sie Indizes übersehen haben.
• Cache sinnvoll (Caching Application Block)
• Behalte ViewState im Auge
• Verwenden Sie Fiddler, um die Seitengröße usw. zu überprüfen.

Wenn Ihre Webserver von einer großen Anzahl gleichzeitiger Anfragen betroffen sind und jede Seitenanforderung länger und länger zu warten scheint, sollten Sie die Konvertierung in das asynchrone Seitenverarbeitungsmodell .

Skalierbare Apps mit asynchroner Programmierung in ASP.NET