0
Ich schreibe einen Client, der häufig kleine Teile von Daten über HTTPS sendet. Die Daten können von 50 UTF-8-Zeichen bis 10k-Zeichen reichen - hauptsächlich von Menschen lesbare Protokolldaten. Ich verwende RFC-Standard-HTTP-Komprimierung.Wann HTTP POST Daten zu komprimieren?
Ich muss für den CPU-Verbrauch optimieren. Ich frage mich, ob es einen Schwellenwert gibt, etwa wie folgt: Wenn eine Zeichenfolge mehr als 100 Zeichen ist, dann lohnt es sich, die Komprimierung durchzuführen.
Sollte ich immer eine Komprimierung für HTTP-Payload anwenden oder nur wenn es sich lohnt?
Danke für Ihre Antwort. Wenn ich den CPU-Profiler verwende, kommt die Auslastung für die Komprimierung an erster Stelle. Daher versuche ich, die Auswirkungen zu reduzieren. Re SSL Session Cache - guten Ruf, ich habe überprüft, es war bereits eingeschaltet. In der Tat ist es standardmäßig für CURL (die ich verwende). – oleksii
Muss ich annehmen, dass die Komprimierung außerhalb von CURL durchgeführt wird? (Ich glaube nicht, dass CURL native Unterstützung für die POST-Datenkomprimierung bietet.) Können Sie versuchen, die Größe des Schiebefensters von DEFLATE zu reduzieren, um die Belastung für große Dateien zu reduzieren? (vorausgesetzt, dass es in Ordnung ist, die Kompressionsraten etwas zu reduzieren). Werden die Dateien nach der Komprimierung zwischengespeichert? (Wenn das in Ihrem Projekt überhaupt Sinn macht.) – Arnauld
Die Komprimierung erfolgt außerhalb von CURL, sie unterstützt keine Inhaltskomprimierung für HTTP-POSTs. Ich sende ein Äquivalent von Echtzeit-Logs, also ist die Größe eines Schiebefensters schon ungefähr eine Sekunde. Unter hoher Last (10k Nachrichten/Sek.) Bekomme ich durch die Komprimierung eine Menge Vorteile. Ich könnte mit dem Kompressionsverhältnis spielen - daran habe ich nie gedacht. Danke für Ihre Hilfe. – oleksii