PRNext Ausdauertest: zwei Stunden und 1,738 Änderungen

#Eine Sitzung mit echten Bearbeitungen und echten Browsern

Der Lauf dauerte 7,201 Sekunden und führte zu 1,738 JavaScript und CSS-Änderungen. Vier Chromium-Registerkarten dienten als App-Router- und Pages-Router-Geräte. Absichtliche Syntaxfehler unterbrachen die Sequenz 28 Mal, um die Wiederherstellung zu testen.

Die Browserprüfungen behielten eine Dokumentmarkierung und einen Komponentenstatus bei, anstatt eine HTTP 200-Antwort als ausreichend zu betrachten. Die Arbeitslast überprüfte auch die Reihenfolge der gestreamten Antworten und die Hintergrundarbeit, die nach der Antwort auf den Cache zugreift.

Das Szenario führte auch 175-Serveraktionsaufrufe durch. Jede Antwort musste zur erwarteten Anwendungsgeneration gehören und durfte nicht nur auf der Transportebene erfolgreich sein. Bei der Syntaxwiederherstellung musste die Seite nach der Reparatur der Quelle in einer nutzbaren Ausgabe wiederhergestellt werden, ohne dass der Status in nicht zugehörigen Registerkarten zurückgesetzt wurde.

Vier Browser-Registerkarten mit beibehaltenem Dokument- und Komponentenstatus. 28 Wiederherstellungen nach erzwungenen Syntaxfehlern. 174-Streaming und 174 Hintergrund-/Cache-Prüfungen. Keine vom Browser-Harness aufgezeichneten Seitenfehler.

#Messen Sie den Servicebaum, nicht nur einen Prozess

Der abgetastete Prozessbaum umfasste Node.js, esbuild und den nativen Rust-Dienst. Seine maximale proportionale Satzgröße betrug 536.51 MiB. Das Wachstum zwischen den definierten Steady-State-Fenstern betrug 59.05 MiB, mit höchstens zehn abgetasteten Prozessen.

Diese Messwerte blieben innerhalb des Ressourcenbudgets des Tests. Es handelt sich um Beobachtungen für diese Vorrichtung, Probenahmemethode und Maschine; Sie sind keine universelle Speicheranforderung oder ein Beweis dafür, dass kein Leck vorhanden sein kann.

Würde man nur den nativen Dienst zählen, würden die Kosten für die JavaScript-Worker und Compiler-Helfer verschleiert. Die proportionale Satzgröße berücksichtigt auch den gemeinsam genutzten Speicher anders als die Summe der residenten Satzmesswerte. Das Spitzen- und Steady-State-Wachstum gehört daher zu ihrer Stichprobenmethode, wenn ein anderer Lauf mit diesen Zahlen verglichen wird.

#Machen Sie den getesteten Schnappschuss deutlich

Bei dem zweistündigen Lauf wurde ein eingefrorener Snapshot verwendet, bevor der endgültige .mts/.cts-Framework-Boundary-Guard hinzugefügt wurde. Die bearbeiteten Quellen waren JavaScript und JSX. Die letzte Wache erhielt separate Regressions-, Verpackungs- und Plattformkontrollen sowie einen kürzeren Rauchlauf mit vier Tabs.

Ein zusätzlicher Dateisystem-Aufbewahrungsmonitor wies ebenfalls eine 25-minute-Sampling-Lücke auf. Die primären Browser- und Speicherprüfungen wurden fortgesetzt. Die Einhaltung dieser Grenzen im Bericht ist wichtiger als die Darstellung eines ununterbrochenen Ergebnisses, das nie gemessen wurde.

Die Unterscheidung zwischen Snapshots ist für sicherheitsrelevante Fixes wichtig. Der spätere Grenzwächter verfügt über seine eigenen vorübergehenden Regressions- und Lebenszyklusnachweise, aber diese Überprüfungen können die Quelle, die zwei Stunden lang lief, nicht im Nachhinein ändern. Durch das Führen beider Aufzeichnungen ist es möglich, genau zu verstehen, was jedes Ergebnis ausmacht.

#Was wir aus dem Ergebnis mitnehmen

Bei dieser Arbeitslast von Linux x64 kam es zu wiederholten Bearbeitungs- und Wiederherstellungsarbeiten sowie zu Ressourcenbudgets. Windows x64 erhielten eine separate Paket-, Lebenszyklus- und Browservalidierung. Separate Browser-Regressionen überprüfen auch die Zustandserhaltung für anonyme Standardkomponenten und neue Serveraktionsantworten.

Es validiert weder macOS noch ARM64, ersetzt keine anwendungsspezifischen Tests und zeigt keinen neuen Leistungsvorteil gegenüber Next.js. Das sind separate Fragen mit separaten Messungen.

Halten Sie für eine anwendungsspezifische Prüfung mehrere repräsentative Seiten geöffnet, interagieren Sie mit ihnen, bevor Sie sie bearbeiten, und schließen Sie einen absichtlichen Syntaxfehler ein, gefolgt von einer Reparatur. Beobachten Sie Browserfehler und den Service-Prozessbaum sowie die Build-Dauer. Dadurch wird die Kontinuität der Arbeit getestet, anstatt die gesamte Sitzung auf die schnellste Aktualisierung zu reduzieren.

So vergleichen Sie die Leistung von React SSR

Hohe Next.js-Speichernutzung: So diagnostizieren Sie sie

PRNext 0.1.18 versus Next.js: CPU, RAM und Schlaf