Wir müssen eine csv-Datei exportieren, die Daten aus dem Modell von Django admin enthält, das auf Heroku läuft. Daher haben wir eine Aktion erstellt, in der wir den csv erstellt und in der Antwort zurückgegeben haben. Dies funktionierte gut, bis unser Client begann, riesige Datenmengen zu exportieren, und wir die 30-Sekunden-Zeitüberschreitung des Web-Arbeiters erreichten.
Um dieses Problem zu umgehen, haben wir darüber nachgedacht, das CSV zum Client zu streamen, anstatt es zuerst im Speicher zu erstellen und es in einem Stück zu senden. Trigger war diese Information:
Cedar unterstützt lange Polling- und Streaming-Antworten. Ihre App hat ein anfängliches 30-Sekunden-Fenster um mit einem einzelnen Byte zurück zum Client zu antworten. Nach jedem gesendeten Byte (entweder von & gt; dem Client erhalten oder von Ihrer Anwendung gesendet) setzen Sie ein rollendes 55-Sekunden-Fenster zurück. Wenn keine Daten & gt; gesendet während des 55 Sekunden Fensters wird Ihre Verbindung beendet.
Wir haben daher etwas implementiert, das so aussieht, um es zu testen:
%Vor%Der HTTP-Header des Downloads sieht folgendermaßen aus (von FireBug):
%Vor%"Transfer-encoding: chunked" würde anzeigen, dass Cedar tatsächlich den Inhalt chunkweise streamt, wie wir vermuten.
Problem ist, dass der Download des csv nach 30 Sekunden mit diesen Zeilen im Heroku-Log immer noch unterbrochen wird:
%Vor%Das sollte konzeptionell funktionieren, oder? Haben wir etwas vermisst?
Wir schätzen Ihre Hilfe sehr. Tom
Ich habe die Lösung für das Problem gefunden. Es ist kein Heroku-Timeout, da sonst im Heroku-Protokoll ein H12-Timeout auftritt (Danke an Caio von Heroku, um darauf hinzuweisen).
Das Problem war das Standard-Timeout von Gunicorn mit 30 Sekunden. Nach dem Hinzufügen von --timeout 600 zum Procfile (an der Linie von Gunicorn) war das Problem weg.
Die Procfile sieht jetzt so aus:
%Vor%Tags und Links python django heroku django-admin cedar