Ich habe ein ungewöhnliches Problem. Ich habe einen C ++ Boost.ASIO Webserver, und um eingehende Anfragen zu bearbeiten, verwende ich diesen Code:
%Vor%(wobei "socket_" mein boost :: asio :: ip :: tcp :: socket ist und "response_" ein boost :: asio :: streambuf)
istIch versuche, nur die Header der Anfrage zu erfassen, dann mache ich später eine zweite async_read_until, wobei transfer_exactly mit der "Content-Length" übereinstimmt, die vom Anfrage-Header analysiert wurde. Das Problem ist, dass der obige Code 100-900ms benötigt, um auf einem sehr modernen Server zurückzukehren (Von diesem gelesenen Block bis handle_read_headers () aufgerufen wird). Die eingehende Anfrage sieht folgendermaßen aus:
%Vor%Die Header scheinen mit einem \ r \ n \ r \ n abgeschlossen zu sein, und es löst die handle_read_headers () -Funktion aus, bevor es den ganzen Weg bis EOF liest (es liest also nicht die ganze Seite) - es stolpert tatsächlich die Regex. Und diese Anfragen kommen von Google, daher bin ich mir ziemlich sicher, dass es kein Ende ist.
Gibt es irgendetwas, das ich übersehen könnte, warum es so lange dauert, bis es wiederkommt? Irgendwelche anderen Fänge mit aync_read_until habe ich vielleicht verpasst?
Danke!
BEARBEITEN / AKTUALISIEREN: Okay, jetzt bin ich sehr verwirrt. Beim Versuch, Megabytes Vorschlag auszuprobieren, wechselte ich von einem streambuf zu einem Zeichen-Array (kein Glück), dann refactored ich meinen Code, um async_read_some statt async_read_until zu verwenden, und scanne nur manuell nach dem Begrenzten. Ich setze auch alle OS-Variablen (sysctrl.conf) auf Bone-Stock-Standard zurück (um die Möglichkeiten einzuschränken). Leider sehe ich immer noch 100-900ms Verzögerungen im folgenden Code vom Aufruf von handle_read () mit der gleichen eingehenden POST-Anfrage:
%Vor%wo response_ jetzt ist:
%Vor%Ohne Erfolg (gleiche Verzögerungen von 100-900ms). Es gibt keine Möglichkeit das ist normal - irgendwelche Gedanken?
EDIT2: Gemäß der Empfehlung von Rhashimoto habe ich das Handler-Tracking aktiviert und diese Kuriosität im Protokoll gefunden:
%Vor%Zwischen async_accept und async_receive liegen mehr als 700 Millisekunden. Im Code geht es von diesem Block aus (quasi direkt aus dem "HTTP Server 2" von Ссылка - server.cpp und connection.cpp):
%Vor%und von Anfang an () bis:
%Vor%und wenn handle_read_headers () aufgerufen wird, sind 700ms vergangen.
Hat jemand irgendwelche Ideen? Ich bin völlig verloren.
Vielen Dank!
Schauen wir uns das Handler-Protokoll an
%Vor% Vom Log können wir sehen, dass async_receive zweimal aufgerufen wird: zuerst wird (# 508) 734ms nach dem Handler-Setup aufgerufen (# 506). Nun wird das zweite async_receive (# 510) 53 Mikrosekunden nach dem Handler-Setup aufgerufen (# 508). Das war es, der zweite Handler-Aufruf wurde blitzschnell abgefeuert, weil die Daten (diese 404 Bytes) bereits im TCP-Stack bereit waren.
Fazit : Es handelt sich nicht um eine Handler-Aufrufverzögerung, sondern um eine Transportverzögerung. Wahrscheinlich Ärger mit dem ISP oder einem Balancer, oder vielleicht will Google Sie wirklich nicht mit Anfragen und Verzögerungen einrichten.
UPD: Ich denke, du kannst das mit tcpdump
P.S. Ich mag nicht io_service_pool_ Implementierung von HTTP-Server 2 Beispiel. Dies kann einige Probleme verursachen, aber ich denke, es ist nicht der Fall.
Tags und Links c++ boost boost-asio