Heroku Sporadische Hohe Reaktionszeit

Question

Dies ist sehr spezifisch, aber ich werde versuchen, sich kurz zu fassen:

Wir sind eine Django App auf Heroku läuft. Drei Server:

1. Test (1 Netz, 1 Sellerie dyno)
2. Training (1 Netz, 1 Sellerie dyno)
3. prod (2 web, 1 Sellerie dyno).

Wir verwenden Gunicorn mit gevents und 4 Arbeiter auf jeder dyno.

Wir sind sporadisch hohe Servicezeiten. Hier ein Beispiel von Loggetries:

High Response Time: 
heroku router - - at=info 
method=GET 
path="/accounts/login/" 
dyno=web.1 
connect=1ms 
service=6880ms 
status=200 
bytes=3562 

Ich google dies seit Wochen. Wir sind nicht in der Lage, sich nach Belieben zu reproduzieren, sondern erleben diese Warnungen 0 bis 5 Mal am Tag. Bemerkenswerte Punkte:

• Tritt auf allen drei Anwendungen (alle laufenden ähnlichen Code)
• Tritt auf verschiedenen Seiten, darunter einfache Seiten wie 404 und/admin
• Tritt zu zufälligen Zeiten
• Tritt mit variierendem Durchsatz. Eine unserer Instanzen fährt nur 3 Benutzer/Tag. Es hängt nicht mit schlafenden Dynos zusammen, weil wir mit New Relic pingen, und das Problem kann während der Sitzung auftreten
• Kann nicht reproduziert werden nach Belieben. Ich habe dieses Problem persönlich einmal erlebt. Das Klicken auf eine Seite, die normalerweise in 500ms ausgeführt wird, führte zu einer Verzögerung von 30 Sekunden und schließlich zu einem App-Fehlerbildschirm von Herokus 30s Zeitüberschreitung
• Hohe Antwortzeiten variieren von 5000ms - 30000ms.
• New Relic weist nicht auf ein bestimmtes Problem hin. Hier sind die letzten Transaktionen und Zeiten:
  • RegexURLResolver.resolve 4,270ms
  • SessionMiddleware.process_request 2,750ms
  • Login Render.html 1,230ms
  • WSGIHandler 1,390ms
  • Die oben genannten sind einfach Anrufe und nehmen Sie nicht normalerweise in der Nähe dieser Menge an Zeit

Was ich habe es verengt zu:

1. This article on Gunicorn and slow clients
   • Ich habe dieses Problem mit langsamen Clients, aber auch in unserem Büro, wo wir eine Glasfaserverbindung haben, gesehen.
2. GEVENT und async Arbeiter spielen nicht schön
   • Wir gewechselt haben sync Arbeiter und Problem noch gunicorn weiterhin besteht.
3. Gunicorn Arbeiter Timeout
   • Es ist möglich, dass die Arbeiter irgendwie am Leben erhaltenen werden in einem Null-Zustand.
4. Zu wenig Arbeiter/dynos
   • Keine Anzeige von CPU/Speicher/db Überauslastung und New Relic keine Anzeichen von DB Latenz
5. Laute Nachbarn zeigen
   • Unter meinen mehreren E-Mails mit Heroku hat der Support-Mitarbeiter erwähnt, dass mindestens einer meiner langen Anfragen auf einen lauten Nachbarn zurückzuführen war, aber nicht überredet wurde Das war das Problem.
6. Subdomäne 301
   • Die Anforderungen, die durch feine kommen, sondern zufällig in der Anwendung stecken zu bleiben.
7. Dynos Neustart
   • Wenn dies der Fall wäre, würden viele Benutzer betroffen sein. Außerdem kann ich sehen, dass unsere Dynos kürzlich nicht neu gestartet wurden.
8. Heroku Routing/service Ausgabe
   • Es ist möglich, dass der Heroku Service ist weniger als angekündigt und dies ist einfach ein Nachteil ihren Dienst zu verwenden.

Wir haben seit den letzten Monaten dieses Problem zu haben, aber jetzt, dass wir die Skalierung es repariert werden muss.Irgendwelche Ideen würden sehr geschätzt werden, da ich fast jeden SO oder Google Link erschöpft habe.

Answer 1

Ich habe in den letzten 6 Monaten Kontakt mit dem Support-Team von Heroku gehabt. Es ist eine lange Zeit der Verengung durch Versuch/Irrtum gewesen, aber wir haben das Problem identifiziert.

Ich bemerkte schließlich, dass diese hohen Antwortzeiten einem plötzlichen Speicherwechsel entsprachen, und obwohl ich für ein Standard-Dyno zahlte (das nicht im Leerlauf war), fanden diese Speicher-Swaps statt, als meine App kürzlich keinen Datenverkehr empfangen hatte. Es wurde auch klar, dass es sich bei den Metrikdiagrammen nicht um ein Speicherleck handelte, da der Speicher sich abflachte. Zum Beispiel:

Nach vielen Gesprächen mit ihrem Support-Team, ich diese Erklärung zur Verfügung gestellt wurde:

Im Wesentlichen was passiert ist, einige Back-End-Laufzeiten mit einer Kombination von Anwendungen am Ende, die am Ende genügend Speicher verwenden, den die Runtime tauschen muss. Wenn dies geschieht, wird ein zufälliger Satz von Dyno-Containern auf der Laufzeit gezwungen, willkürlich um kleine Beträge zu wechseln (beachten Sie, dass "zufällige" Container wahrscheinlich Speicher sind, auf den kürzlich nicht zugegriffen wurde, der aber immer noch im Speicher vorhanden ist). Gleichzeitig werden die Apps, die große Mengen an Speicher verwenden, ebenfalls stark ausgelagert, was mehr Laufzeit zur Folge hat als normal.

Wir haben nicht geändert, wie fest wir die Laufzeiten packen, seit dieses Problem immer offensichtlicher geworden ist. Unsere aktuelle Hypothese ist, dass das Problem von Kunden kommt, die von Versionen von Ruby vor 2.1 zu 2.1+ wechseln. Ruby macht einen großen Prozentsatz der Anwendungen aus, die auf unserer Plattform laufen, und Ruby 2.1 hat Änderungen an seinem GC vorgenommen, der die Speicherauslastung mit der Geschwindigkeit vergleicht (im Wesentlichen werden GCs weniger häufig verwendet, um Geschwindigkeitsgewinne zu erzielen). Dies führt zu einer merklichen Erhöhung der Speichernutzung für jede Anwendung, die von älteren Versionen von Ruby ausgeht. Daher würde die gleiche Anzahl an Ruby-Apps, die zuvor eine bestimmte Speicherauslastungsebene beibehalten haben, jetzt mehr Speicherverbrauch erfordern.

Dieses Phänomen kombiniert mit unsinnigen Anwendungen, die Ressourcenmissbrauch auf der Plattform haben, traf einen Wendepunkt, der uns zu der Situation brachte, die wir jetzt sehen, wo Dynas, die nicht ausgetauscht werden sollten, sind. Wir haben ein paar Angriffswege, die wir untersuchen, aber im Moment sind viele der oben genannten Punkte noch ein wenig spekulativ.Wir sind uns jedoch sicher, dass dies teilweise durch missbräuchliche Anwendungen verursacht wird. Aus diesem Grund sollte das Problem nicht auftreten, wenn Sie zu Performance-M- oder Performance-L-Dynoden (mit dedizierten Backend-Laufzeiten) wechseln. Die einzige Speicherbelegung auf diesen Dynoden ist Ihre Anwendung. Also, wenn es einen Swap gibt, wird es sein, weil Ihre Anwendung es verursacht.

Ich bin zuversichtlich, dass dies das Problem ist, ich und andere haben erlebt, wie es um die Architektur selbst und nicht auf eine beliebige Kombination von Sprache/Rahmen/configs verwandt ist.

Es scheint nicht eine gute Lösung, die nicht A) zäh und warten Sie es aus oder B) Schalter auf einer ihrer speziellen Instanzen

Ich bin mir bewusst, der Menge zu sein, die „Das sagt Deshalb sollten Sie AWS verwenden ", aber ich finde, dass die Vorteile, die Heroku bietet, einige gelegentlich hohe Antwortzeiten überwiegen und ihre Preise im Laufe der Jahre besser geworden sind. Wenn Sie unter dem gleichen Problem leiden, wird die "beste Lösung" Ihre Wahl sein. Ich werde diese Antwort aktualisieren, wenn ich noch etwas höre.

Viel Glück!

Answer 2

Ich bin mir nicht sicher, ob das überhaupt hilft, aber ich mache das gleiche mit einer Rails App jetzt auf Heroku - scheinbar nichtdeterministisch sporadisch hohe Anfragezeiten. Zum Beispiel: HEAD Neue Relic-Uptime-Pings zu meinem Site-Index, die normalerweise 2-5ms dauern, was 5 Sekunden dauert, oder das Rendern meiner Site-Anmeldung, die normalerweise eine Subsekunde dauert, die 12 Sekunden dauert. Gelegentlich auch zufällige 30s Timeouts. Hier ist, was Heroku Unterstützung in meinem Fall zu sagen hatte (für einige der Instanzen mindestens):

Die eine frühere heute sieht aus wie ein großer Brocken von Request Queuing nach einem Neustart. Wenn Sie diese vermeiden möchten, sollten Sie sich unsere Preboot feature ansehen. Auf diese Weise können Sie nach einer Bereitstellung ein Matched-Set von Dynos starten und anschließend Anfragen an sie übergeben, anstatt die vorhandenen Dynos zu überspringen und die Anforderungswarteschlange zu erzwingen.

Ich nehme zur Kenntnis sollte, war dies eine der Standard-dyno Neustarts des Heroku, kein deploy von mir oder irgendetwas. Trotz der Vorbehalte auf der Preboot-Seite habe ich es vor ein paar Minuten aktiviert, also werden wir sehen, ob es in meinem Fall einen Unterschied macht. Hoffe, das könnte helfen, da ich mir auch deswegen die Haare rausgezogen habe!