ASP.NET Seite Leistung

Question

Wir haben eine ziemlich komplexe Seite, die die Benutzersteuerelemente dynamisch lädt (einige von ihnen sind verschachtelt). Es ist eine sehr langsame Seite.

Könnte das Hinzufügen der Steuerelemente dynamisch zum Engpass hinzugefügt werden? Wäre es hilfreich, wenn wir das Steuerelement im .NET-Cache-Objekt hinzufügen und LoadControl nicht verwenden, wenn es bereits im Cache vorhanden ist?

Weitere Tipps/Strategien, um die Seite schneller zu machen?

Answer 1

Fügen Sie Trace = "true" zu Ihrer @ Page-Direktive hinzu und Sie werden sehen können, welche Methoden am längsten dauern.

Answer 2

Ich würde bezweifeln, dass es der Vorgang des dynamischen Ladens von Steuerelementen ist, die es verlangsamt und mehr das Verhalten jedes Steuerelements. Treffen sie alle die DB? Ich würde sehen, wenn Sie die Leistung der Steuerelemente (Zwischenspeicherung von DB-Aufrufen usw.) rationalisieren könnten, bevor Sie versuchen, ihr Laden zu optimieren.

Answer 3

Wir haben einmal die Leistung eines ASP.Net-Projekts um eine Größenordnung verbessert. Hier ist eine Liste der Dinge, die wir versucht haben:

• Set SessionState zu false oder ReadOnly wenn möglich. Beachten Sie, dass sich die Methode zum Festlegen des Sitzungsstatus für ASPages, Webdienste und Anwendungen unterscheidet.
• Sitzungsstatus während des Vorgangs speichern, wenn möglich.
• Setzen Sie EnableViewState wenn möglich auf false.
• Zwischenspeichern verwenden, wenn möglich.
• Verwenden Sie HTML-Steuerelemente anstelle von serverseitigen Steuerelementen, wenn Sie vom Server keinen Zugriff auf das Steuerelement benötigen.
• Vermeiden Sie nach Möglichkeit Rundreisen (Daten an den Server senden und die Seite neu laden). Beachten Sie, dass Sie nur zum Lesen von Daten aus dem Server oder zum Schreiben von Daten auf den Server round-trip müssen. Validierung und Feedback können clientseitig erfolgen. Verwenden Sie die IsPostBack-Eigenschaft in Page_Load, um zu vermeiden, Daten für Postback neu zu generieren.
• Verwenden Sie die StringBuilder-Klasse für wiederholte Verkettung.
• Verwenden Sie Try/Catch-Blöcke nur für unerwartete Situationen; Verwenden Sie sie nicht als allgemeine Kontrollkonstrukte.
• Verwenden Sie frühzeitige Bindung so viel wie möglich. Mit anderen Worten, vermeide Reflexionen.
• Vermeiden Sie nicht verwalteten Code wie COM.
• Debug-Modus für Versand-Apps deaktivieren.
• Verwenden Sie gespeicherte Prozeduren für den Datenbankzugriff statt SQL-Zeichenfolgen.
• Verwenden Sie die DataReader-Klassen zum Lesen von Daten anstelle von DataSets.
• Verwenden Sie möglichst restriktive Klassen wie SqlDataReader anstelle von DbDataReader.

Answer 4

Ich würde einige Profiling auf der Seite tun, um zu sehen, wo die wahren Verlangsamungen auftreten. Meiner Erfahrung nach, was meiner Meinung nach die Verlangsamung in Wirklichkeit verursacht, sind nicht die langsamsten Punkte. Ich habe es am besten gefunden, meine Apps/Seiten zu profilieren, wenn die Dinge langsam laufen, was mir dann sehr gute Informationen darüber gibt, in welchen Bereichen ich am schnellsten beschleunigen könnte, um dramatische Improvisationen zu bekommen. Sie könnten feststellen, dass es zu viele DB-Aufrufe oder das Laden des Benutzersteuerelements oder etwas anderes, das Sie nicht berücksichtigt haben, ist.

Answer 5

Ich wäre ein wenig überrascht, wenn das einfache Laden der Steuerelemente dynamisch hohe Kosten verursacht.Wenn es jedoch viele Steuerelemente gibt, die tief verschachtelt sind, kann ASP.NET manchmal sehr langsam sein, um sie in HTML zu rendern. Offensichtlich, Profiling wie andere vorgeschlagen haben, um festzustellen, wo Ihr Engpass wirklich liegt.

Eine Sache zu überprüfen, für eine komplexe Seite, ist die Größe des gerenderten HTML. Bei vielen Serversteuerelementen kann die Seitengröße erstaunlich schnell auf mehrere Megabyte steigen. Aktivieren oder optimieren Sie Ihre HTTP-Komprimierung möglicherweise die Antwort, die Sie suchen.

Answer 6

Der erste Schritt bei der Untersuchung von Leistungsproblemen ist die Identifizierung des Engpasses: Ist es Netzwerkverkehr (zu viele HTTP-Anfragen? Zu viel HTML kommt die Pipe?) Oder CPU gebunden auf dem Server? oder zu viele Datenbankaufrufe?

In vielen Fällen ist es die schiere Größe der Seite, die Verlangsamungen verursacht. Wenn Sie eine Menge Steuerelemente auf Ihrer Seite hinzufügen, wird es eine Menge HTML geben. Wenn Sie also eine Ansichtsquelle für das fertige gerenderte Produkt erstellen und 20000 Zeilen HTML/JavaScript finden, ist die Verlangsamung wahrscheinlich zu groß Daten werden über das Netzwerk gesendet.

Ich empfehle, ein Tool wie YSlow zu verwenden, um das fertige gerenderte Produkt besser zu verstehen.

Key Artikel zu sehen:

• die Größe Ansichtszustand Verwalten
• Sicherstellen, dass Teile der Seite, die zu .Visible gesetzt versteckt = False (statt nur style = "display: none; „)
• zentralisieren und zu konsolidieren JavaScript
• die Anzahl der HTTP Minimierung anfordert

Answer 7

Ladebenutzersteuer dynamisch ist definitiv nicht der Grund für langsame Leistung. Eine Sache, die eine Leistung der ASPX-Seite drastisch einschränkt, ist Viewstate. Ich würde empfehlen, Viewstate aus der Seite zu nehmen [auch wenn Sie es auf einigen der Steuerelemente aktiviert haben].

Speichern Sie den gesamten Viewstatus als Sitzungsvariable auf dem Server und übertragen Sie den Bezeichner nur im Viewstate-Feld. Sie können einen Blick auf den vollständigen Artikel here werfen, der Artikel gibt auch Kennzahlen zur Leistungsmessung.

Answer 8

Es gibt so viele Gründe, warum eine Webseite langsam sein kann. Sie müssen wirklich einige Tools wie den Performance Wizard verwenden, um herauszufinden, was los ist.

Unsere neuesten Performance-Probleme gingen auf anonyme Typen und linq zurück. Es ist so einfach, die Performance mit diesen beiden Dingen zu beenden, da das JIT-Compiling immer noch läuft.