Zufällig hohe Downloadzeit in Chrome?

8

Wir haben eine API, die zufällig eine hohe content download -Zeit in Chrome annimmt. Sie funktioniert immer in Firefox und benötigt nur ein paar ms . Die Antwortgröße ist 20 KB unkomprimiert und 4 KB komprimiert. Die gleiche Anfrage funktioniert auch gut mit Curl.

Dinge, die wir versucht haben:

  1. Deaktivieren des Headers If-None-Match , um die Cache-Antwort vom Browser zu deaktivieren.
  2. Versuche verschiedene Kompressionen (gzip, deflate, br).
  3. Komprimierung wird deaktiviert.
  4. Deaktivieren aller Chrome-Erweiterungen.

Die gleiche Anfrage funktioniert manchmal auch in chrome, gibt aber nach dem Zufallsprinzip eine Downloadzeit mit sehr hohem Inhalt zurück.

Wir können die Ursache dieses Problems nicht verstehen. Welche anderen Dinge können wir versuchen, diese Zeit zu minimieren?

Ich habe hier drei Anfragen gestellt und die dritte hat die meiste Zeit gebraucht (vor der letzten Spitze). Die CPU scheint für einen längeren Zeitraum nicht ausgeschöpft zu sein. Die meiste Zeit ist Leerlaufzeit.

Wenn Sie den Anruf mit dem Replay XHR -Menü wiederholen, sinkt die Downloaddauer für Inhalte von 2 Sekunden auf 200 ms.

    
rajat 28.11.2017, 04:49
quelle

2 Antworten

13

Versuchen Sie zufällig, unendliches Scrollen zu implementieren? Wenn dies der Fall ist, versuchen Sie, die Bildlaufleiste zu ziehen, anstatt das Mausrad zu verwenden. Aus irgendeinem Grund scheint Chrome mit Maus-Scroll-Ereignissen zu kämpfen. Wenn die Bildlaufleiste einwandfrei funktionierte, lesen Sie weiter.

Dieser Beitrag bietet eine detaillierte Anleitung für jemanden, der etwas Ähnliches erlebt - Ссылка

Ich hatte einen Beobachter an das Ereignis scroll angehängt, das eine AJAX-Anfrage auslösen würde. Ich hatte die Anfrage gedrosselt und konnte sehen, dass nur 1 gesendet wurde. Ich beobachtete, wie mein Dev-Server die Antwort innerhalb von ein paar ms zurücksendet, aber es würde eine Verzögerung von 2 Sekunden in Chrome geben. Kein Render, keine API-Aufrufe, keine und Skripte ausgeführt. Aber der "Content Download" würde 3 Sekunden für 14kb dauern. Kein anderer Browser hatte dieses Problem.

Ich bin auf Vorschläge gestoßen, dass die Verwendung von requestAnimationFrame anstelle von setTimeout das Problem lösen würde. Dieser Ansatz scheint zu funktionieren, wenn das "Warten" oder Grün signifikant ist, nicht so sehr für den "Inhalt herunterladen" oder blau.

Nach Stunden des Grabens habe ich versucht, e.preventDefault() auf dem mousewheel -Ereignis anzurufen und zu meinem Erstaunen hat es funktioniert.

Ein paar Dinge zu beachten:

1) Ich habe das mousewheel -Ereignis nicht benutzt, um den API-Aufruf zu machen. Ich habe das scroll -Ereignis zusammen mit der Drosselung verwendet.

2) Das Ereignis mousewheel ist nicht standardisiert und sollte nicht verwendet werden. Siehe Ссылка

3) ABER in diesem Fall müssen Sie das mousewheel -Ereignis wegen Chrome beobachten und verarbeiten. Andere Browser ignorieren das Ereignis, wenn sie es nicht unterstützen, und ich habe es noch sehen, ein Problem in einem anderen Browser verursachen.

4) Sie möchten preventDefault() nicht jedes Mal aufrufen, da dies das Scrollen mit der Maus deaktiviert :) Sie möchten es nur aufrufen, wenn deltaY 1 ist, wenn Sie den vertikalen Bildlauf verwenden. Sie können aus dem angehängten Bild sehen, dass deltaY 1 ist, wenn Sie nicht mehr scrollen können. Das Ereignis mousewheel wird ausgelöst, obwohl die Seite nicht scrollen kann. Als Randnotiz ist deltaX -0, wenn Sie vertikal scrollen, und deltaY ist -0, wenn Sie horizontal scrollen.

Meine Lösung:

%Vor%

Das war die einzige Lösung, bei der ich Arbeit gesehen habe, und ich habe sie nirgends erwähnt oder diskutiert. Ich hoffe, das hilft.

Konsolenprotokoll des Mausrad-Ereignisses

    
JK Slyby 06.12.2017, 22:07
quelle
-1

Ich denke, Sie können es falsch machen. ™

Grundsätzlich, wenn das wirklich nur mit Chrome passiert, dann ist vielleicht der clientseitige Code schuld, von dem Sie keine Details preisgeben.

Andernfalls versuchen Sie, das, was Sie als Back-End-Bedingung präsentieren (basierend auf der Auswahl des nginx-Tags) mit Front-End-Tools zu debuggen:

  • Haben Sie versucht, tcpdump(8) zu verwenden, um das Problem zu beheben? Welche Pakete werden zu welchen Zeiten ausgetauscht?

  • Haben Sie versucht, die Zeiten der Anfrage zu protokollieren, die von nginx empfangen und verarbeitet wurde? Zum Beispiel $request_time ?

  • Wo befindet sich der Server? Vielleicht haben Sie einen Paketverlust, der Timeouts und die erneute Übertragung einiger TCP-Pakete erfordern kann, was unweigerlich zu einer zufälligen Verzögerung führt?

Schließlich ist die letzte Möglichkeit, dass das Feld nicht das bedeutet, was du denkst - es klingt, als könnte es einen Treffer von der CPU-Last nehmen, da dies das Ergebnis von XMLHTTPRequest ( XHR ) ist Verarbeitung - vielleicht führen Sie etwas Werbung mit Benutzerverfolgung, die nach dem Zufallsprinzip eine erhebliche Menge an CPU verbraucht, verlangsamen Sie Ihre Metriken?

    
cnst 04.12.2017 07:19
quelle