ASP.Net übermäßige Verwendung von User Controls
Ich bin untersucht eine asp.net web-Anwendung, die ausgiebig verwendet User Controls auf jeder Seite. Die meisten Seiten enthalten etwa 10 bis 20 Benutzer-Steuerelemente. Der Benutzer steuert, scheinen die visuelle Darstellung der business Objekte (wenn das Sinn macht), obwohl eine feinere Granularität wie jeder tab ein tab-control, das seinen Inhalt in einem Steuerelement. Das Projekt selbst hat über 200 Benutzersteuerelemente (ascx-Dateien).
Die performance der Anwendung ist sehr schlecht (und der Grund, warum ich mich untersuchen). Jedes Ereignis (wie einen Klick oder dropdown-Auswahl etc) benötigt etwa 5 Sekunden, die Seite zu laden (10 Sekunden, während in visual studio). Die Anwendung hat keine Verwendung von Ajax.
Tracing schmerzhaft ist, wie die aspx-Seiten, die selbst keinen code in der code-behind als der Benutzer steuert sich nach all dies, so dass die Verfolgung einer einzigen Seite benötigt trace-Anweisungen in allen user-controls, die sich auf dieser Seite.
Ich glaube tatsächlich, dass jeder Benutzer die Kontrolle sich nach deren Geschäfts-code und re-nutzbar, ist eine kluge Idee, aber eine übermäßige Verwendung von Benutzer-Steuerelementen werde, fällt eine performance-hit? Scheint dies, wie die Struktur einer asp.net Anwendung, die geschrieben wurde von jemandem mit einem starken WinForms hintergrund?
BEARBEITEN
dachte, ich sollte hinzufügen, dass ich bin nicht in Frage die Verwendung von user controls (oder auch der Betrag), sondern nur, ob dass so viele auf eine Seite, die alle vollbringen (jeder Benutzer-Steuerelement mit der Datenbank zum Beispiel) wird in der Regel dazu führen, dass performance-Probleme...Zum Beispiel, wenn nur ein Benutzer die Kontrolle postsback, etwas zu tun, was über die Verarbeitung all der anderen, einige sind sichtbar, und einige sind't...@David McEwing erwähnt, dass er 40 optimierte Benutzer-Steuerelemente ausführen usw. aber wenn der Entwickler war WinForms-basierten oder "nicht vertraut mit asp.net", dann wie werden Sie sicherstellen, dass jeder ist optimiert...
EDIT2
Nachdem Sie eine sql-Anweisung trace, die gleichen Aufrufe für Daten ausgeführt werden 5-6 mal pro Seite rufen Sie für jede Veranstaltung, wie die verschiedenen Benutzer-Steuerelemente erfordern Daten, die nicht gespeichert wird, Häufig z.B. jedes Steuerelement in der Registerkarte (oben erwähnt) macht das gleiche Aufruf zum füllen eines Objekts aus der Datenbank...ich bin wirklich nicht hier, um anzuklagen, user-controls für das problem (soll ich löschen der Frage?) so klar das problem ist NICHT user-controls aber mit der Verwendung von in diesem besonderen Fall...das glaube ich ist übertrieben!
- Die Leistung ist nicht relevant, da effektiv es ist einfach so, dass die Steuerelemente alle auf der Seite. Das eigentliche problem ist nur, wie viel Arbeit, die Seite nicht; das ist die einzige Gegenleistung. Nicht, wenn es in ein Benutzersteuerelement oder nicht.
- Wenn es nichts ist, was man tun kann, über die Bedienelemente, vielleicht können Sie konvertieren einige von Ihnen in custom web controls? Nicht wirklich sicher, ob Vorkompilierung wird helfen, ist aber nur ein Gedanke.
Du musst angemeldet sein, um einen Kommentar abzugeben.
10-20 (oder sogar Hunderte) der Nutzer Steuert Sie allein ist jenseits trivial. Die Anwesenheit der Steuerelemente selbst, und die Idee der Kapselung, ist definitiv nicht die Quelle der Probleme.
Es ist unmöglich zu sagen genau, was das problem ist, ohne tatsächlich profiling der Anwendung natürlich, aber basierend auf meiner Erfahrung kann ich sagen:
Was wahrscheinlicher ist, ist die konkreten Umsetzung der business-Logik in jedem Benutzer-Steuerelement ist schlecht. Mit postbacks, die so lange wie Sie es beschreiben, jedes Steuerelement sieht wohl zurück zu Ihrem DAL für seine eigenen Daten bei jeder Anfrage. Dies kann gemildert werden durch zwei Dinge:
Dann leg ich mich fest in das Lager der Leute, die vorschlagen, es gibt keine harte Grenze, um eine Reihe von Steuerelementen, die verwendet werden sollten, auf einer Seite. Es klingt wie die Anwendungs-Breite der Ablaufverfolgung ist hier anstelle von page-level-tracing. Es kann sehr gut sein, dass eine Handvoll von diesen Kontrollen das problem verursacht. Heck, es sein könnte ein einzelnes Steuerelement verursacht die ganze Aufregung. Jedoch, da es unmöglich zu machen, eine Vermutung über das Ausmaß der Ressourcen-Nutzung, dass der "Durchschnitt" (wenn es so etwas gibt) user-Kontrolle nimmt, ist es ebenso unmöglich, zu empfehlen, ein limit. Sonst würden wir in der Lage, eine ähnliche Begrenzung für die Anzahl der Mitglieder einer Klasse oder der Anzahl der gespeicherten Prozeduren in einer Datenbank.
Nun, wenn wir reden über 20 komplexe Benutzer-Steuerelemente, die jeder abrufen, Ihre eigenen Daten mit jedem refresh und jeder mit einem Bündel von sub-Steuerelemente verwenden die ViewState, ob Sie notwendig sind oder nicht, dann ja, das ist ein problem. Noch, es hat mehr zu tun mit der Gesamtkonzeption als mit es zu viele Kontrollen. Wenn auf der anderen Seite, die Sie erstellt haben, eine gemeinsame Benutzer-Steuerelement zu handeln, als nichts anderes als eine Kombination von einem label auf der linken Seite ein Textfeld (oder vielleicht sogar jede Kombination von label + Benutzer-bedienbare Steuerung) und bestreut diese die Kontrolle über die app, die ich mir vorstellen kann, dass Sie bekommen würde, eine Reihe von diesen auf einer Seite und ich kann nicht sehen, warum, dass möchte unbedingt etwas weh.
Ich nehme an, dass Sie nicht vertraut sind mit Anwendungen, die verwenden so viele Steuerelemente?
Es klingt wie Sie können springen zu dem Schluss, dass diese unbekannten Aspekt der Anwendung ist die Ursache für die ungewohnt schlechte Leistung. Statt Annahmen zu machen, warum nicht versuchen, eine der folgenden profiling-tools, und finden Sie heraus:
Diese können alle Speicher-und CPU-profiling ASP.NET Anwendungen.
Ich glaube, dass einer der wichtigsten Zwecke der Benutzersteuerelemente ist die Wiederverwendung von code. Das heißt, wenn die gleiche Funktionalität tritt auf mehreren web-Seiten, dann ist es besser, erstellen Sie ein Benutzersteuerelement für Sie. Das spart nicht nur die Entwickler vom schreiben (oder kopieren und einfügen) den gleichen code, um mehrere web-Seiten, aber es macht auch die Wartung viel einfacher. Jede änderung der UserControl implementiert wird automatisch überall dort, wo das Benutzersteuerelement verwendet wird. Die Wartungs-Entwickler sich keine sorgen über die Suche nach allen Orten, dass der code geändert werden muss.
Ich bin mir nicht sicher, ob ein single-use-UserControl ist, wie wirkungsvoll. Sie tun, Kapseln und segreate den code, das ist schön, auf einem stark ausgelasteten web-Seite.
Können Sie feststellen, ob Ihre Benutzersteuerelemente wiederverwendet werden, oder sind viele von Ihnen nur einmal verwendet werden.
Ich Stimme mit Saunders über das tun einige-profiling zur Ermittlung der Auswirkungen von bestimmten Dingen haben.
Hinweis, dass man sich eine Kostenlose stress-testing-tools für IIS-hier: http://support.microsoft.com/kb/840671
Ich allerdings sagen, dass zu viele Kontrollen ist wahrscheinlich nicht eine gute Sache, IMHO. Ohne mehr zu wissen, würde ich unter VORBEHALT sagen, 20 ist zu viel.