Wie schnell sollte eine dynamisch generierte Webseite erstellt werden?

Question

Ich habe eine Reihe von datengesteuerten webbasierten Anwendungen, die sowohl für interne als auch für öffentliche Benutzer bestimmt sind, und würde gerne einschätzen, wie schnell eine Seite erstellt werden sollte (in Millisekunden), um die Benutzerzufriedenheit und die Skalierbarkeit zu gewährleisten.

Wie schnell muss also eine Seite erstellt werden, um eine schnelle Website zu erhalten?

Die Sites werden in ASP classic entwickelt, wobei ein SQL Server-Backend XML-Datensätze generiert, die ich mit XSLT rendere. Das ist nicht die effizienteste Technik, und die Erstellung der Seiten dauert je nach Komplexität der Seite zwischen 7 ms und 120 ms (d. h. das Zeitintervall zwischen der ersten Codezeile und der "Response.Write"). Langsamere Seiten sind darauf zurückzuführen, dass die Datenbank größere und komplexere Abfragen durchführt. Selbst wenn ich alle ASP-Klassiker in ASP.NET umschreibe, wird sich die Gesamtgeschwindigkeit des Seitenaufbaus nicht wesentlich verbessern.

Ich habe Jeff oft sagen hören, dass er möchte, dass SO die schnellste Website und seine Blogs haben die Optimierung seiner Code und Datenbank, aber wie weit muss man bei der Optimierung des Codes gehen? Ist die Einsparung von Millisekunden durch die Verwendung von StringBuffer anstelle von String + String eine gute Verwendung meiner Zeit?

[Klarstellung]

Ab welchem Punkt denken Sie: "Der Aufbau dieser Seite dauert zu lange"? Sind es mehr als 20 ms, mehr als 200 ms oder ist es in Ordnung, wenn eine Seite mehr als eine Sekunde zum Aufbau braucht? Was sind Ihre "Zielzeiten"?

Answer 1

Das hängt ganz von Ihrer Zielgruppe und Ihren Zielen ab - ich habe an Anwendungen gearbeitet, bei denen das Zielereignis "onload" bei <4 Sekunden liegt, und an Anwendungen, bei denen die Zeit auf dem Server <1 ms betragen soll. Es kann in beide Richtungen gehen - aber was auch immer Sie tun, Sie müssen sich darüber im Klaren sein, dass alle Leistungsoptimierungen, die Sie auf Server-Ebene vornehmen, wahrscheinlich von der Netzwerkleistung, die immer noch der größte Engpass im Web ist, und den wahrgenommenen Ladezeiten in den Schatten gestellt werden.

Yahoo hat einige ausgezeichnete Leitlinien für die allgemeine Leistung der Website, insbesondere im Bereich der wahrnehmbaren Last.

Hoffentlich sind Sie bereits klug genug, um zu cachen, was Sie können, und die kleinen Dinge zu tun, wie massive Ketten von Response.Writes zu vermeiden...

Answer 2

Den Nutzern ist es egal, wie schnell Sie Ihre Daten aufbereiten, sie interessieren sich nur für die tatsächliche Ladezeit der Seite.

Wenn Sie viel Overhead beim Rendering haben, werden Ihre Nutzer Ihre Website als langsam empfinden. Bei klassischem ASP wird die Verkettung von Strings als sehr schlechte Praxis angesehen, da sie sehr langsam wird, wenn die kritische Stringlänge erreicht wird, ab der sie eine Belastung für den Server darstellt.

Die Verwendung eines Arrays (jscript) oder eines .NET StringBuffers kann die Rendering-Zeit erheblich verbessern. Sowie die Entlastung unnötige CPU-Auslastung, dass Ihr Server mehr Verkehr verarbeiten können würde, würde ich sagen, diese Art von offensichtlichen Optimierung ist sehr wert tun.

Answer 3

Einen sehr interessanten Screencast zu diesem Thema finden Sie hier: Linktext .

Obwohl es von einem Rails-Mitarbeiter erstellt wurde, ist es auch auf andere Frameworks anwendbar.

Answer 4

Wenn Sie durch eine einzige Änderung Millisekunden einsparen können, sollten Sie das tun!

Vielleicht sollten Sie auch einen Blick auf die Zwischenspeicherung von Datenbankanfragen werfen.

Answer 5

Ein Faktor, der die Zufriedenheit des Benutzers mit der Antwortzeit des Servers beeinflusst, ist die Häufigkeit, mit der er eine neue Seite anfordert. Wenn Sie (z.B.) eine Seite mit vielen Informationen präsentieren, für die der Benutzer einige Zeit zum Lesen benötigt, ist eine längere "Rendering"-Zeit in Ordnung. Wenn der Benutzer dagegen schnell durch die Seiten navigiert, möchte er eine nahezu sofortige Antwort erhalten.

Wenn Sie z. B. auf einer Nachrichtenseite sind, ist es für Sie wahrscheinlich in Ordnung, wenn die nächste Seite ein oder zwei Sekunden braucht, da Sie 30 Sekunden brauchen, um sie zu lesen.

Wenn Sie hingegen eine interaktive Karte durchsuchen, möchten Sie wahrscheinlich, dass die Antwort weniger als eine Sekunde dauert.