Some replies inline.
If you'd prefer to talk directly, I'm in the #beast channel of cpplang
Slack: https://cppalliance.org/slack/
On Wed, 25 Nov 2020 at 11:55, Dominique Devienne via Boost-users
Hi. I'm writing a small interaction between: 1) a Boost.Beast-based HTTP server (based on http_server_async.cpp example) 2) a Boost.Beast-based HTTP client (based on http_client_sync.cpp example)
When I log the time it takes to resolve the server address and connect to it, then issue my HTTP request, it takes over 1 second (Win10, VS2019, C++17, Release, localhost for both client and server):
2020-11-25T09:46:37.473936 Prologue in 0.001s 2020-11-25T09:46:37.482470 Resolved in 0.008s 2020-11-25T09:46:38.506180 Connected in 1.023s 2020-11-25T09:46:38.509607 OK: Authenticated; in 0.003s
While the same on Linux (RH7.5) is just over 2ms:
2020-11-25T09:45:45.515926 Prologue in 0.000s 2020-11-25T09:45:45.517083 Resolved in 0.001s 2020-11-25T09:45:45.517550 Connected in 0.000s 2020-11-25T09:45:45.518010 OK: Authenticated; in 0.000s
That's a huge difference! Almost 500x...
And when I contact the same HTTP server on Windows, but from Chrome this time, it takes about 300ms, and if I hit reload rapidly, the time jumps around to as low as 3ms, and as high as 300ms (the same initial delay), with ~50ms and ~100ms in between. (I also see several different connections being established, for some reason...)
Chrome eagerly opens connections and keeps them open for as long as possible. It's probably not a good control in this case.
I've seen similar differences between Windows and Linux connection times, but with WebSocketPP-based client and server this time, also based on Boost.ASIO.
Q1: Am I doing anything wrong? I.e. is this "normal" somehow?
Difficult to say without some code so I can try to repeat your results. Are you in a position to post a small project to github that demonstrates the issue?
Q2: How come Chrome, on Windows too, is 3x faster than ASIO-based clients, with the same Beast-based server?
Difficult to say without investigating in-situ.
Given the high connect time on Windows, I thought I'd try to keep the connection open on the client, and issue several send-request/read-response pairs, using the Beast-based (sync) HTTP client, but only the first one works correctly, the 2nd errors out with:
Error: An established connection was aborted by the software in your host machine
I suspect it is a user-error, with the server closing the connection, despite the Keep-Alive HTTP header being present server-side on the request.
Very likely a user error. I'd guess at a data race or logic error on the client, but difficult to be sure at this stage.
Q3: Given the Beast HTTP examples I'm based off, would anyone have suggestions on what changes are necessary to allow the client issuing several (non-overlapping) requests to the server, on the same connection? (since connecting is so expensive).
You'd have to code up a "connection pool" and separate the concept of a "request/response" from a connection. They would be associated for the duration of the request/response only.
Q4: And for better performance, what about overlapping request/response pairs, with HTTP pipelining. How to set that up on the client and server with Beast?
Overlapping should work since even though requests are processed one at a time on the server, the tcp transmit/receive windows will buffer the traffic. Again, this presupposes separating the concerns of connection and request.
Thanks for any help on this. --DD
Happy to provide more help as more information becomes available. -- Richard Hodges Staff Engineer C++ Alliance hodges.r@gmail.com office: +442032898513 On Wed, 25 Nov 2020 at 11:55, Dominique Devienne via Boost-users < boost-users@lists.boost.org> wrote:
Hi. I'm writing a small interaction between: 1) a Boost.Beast-based HTTP server (based on http_server_async.cpp example) 2) a Boost.Beast-based HTTP client (based on http_client_sync.cpp example)
When I log the time it takes to resolve the server address and connect to it, then issue my HTTP request, it takes over 1 second (Win10, VS2019, C++17, Release, localhost for both client and server):
2020-11-25T09:46:37.473936 Prologue in 0.001s 2020-11-25T09:46:37.482470 Resolved in 0.008s 2020-11-25T09:46:38.506180 Connected in 1.023s 2020-11-25T09:46:38.509607 OK: Authenticated; in 0.003s
While the same on Linux (RH7.5) is just over 2ms:
2020-11-25T09:45:45.515926 Prologue in 0.000s 2020-11-25T09:45:45.517083 Resolved in 0.001s 2020-11-25T09:45:45.517550 Connected in 0.000s 2020-11-25T09:45:45.518010 OK: Authenticated; in 0.000s
That's a huge difference! Almost 500x...
And when I contact the same HTTP server on Windows, but from Chrome this time, it takes about 300ms, and if I hit reload rapidly, the time jumps around to as low as 3ms, and as high as 300ms (the same initial delay), with ~50ms and ~100ms in between. (I also see several different connections being established, for some reason...)
I've seen similar differences between Windows and Linux connection times, but with WebSocketPP-based client and server this time, also based on Boost.ASIO.
Q1: Am I doing anything wrong? I.e. is this "normal" somehow?
Q2: How come Chrome, on Windows too, is 3x faster than ASIO-based clients, with the same Beast-based server?
Given the high connect time on Windows, I thought I'd try to keep the connection open on the client, and issue several send-request/read-response pairs, using the Beast-based (sync) HTTP client, but only the first one works correctly, the 2nd errors out with:
Error: An established connection was aborted by the software in your host machine
I suspect it is a user-error, with the server closing the connection, despite the Keep-Alive HTTP header being present server-side on the request.
Q3: Given the Beast HTTP examples I'm based off, would anyone have suggestions on what changes are necessary to allow the client issuing several (non-overlapping) requests to the server, on the same connection? (since connecting is so expensive).
Q4: And for better performance, what about overlapping request/response pairs, with HTTP pipelining. How to set that up on the client and server with Beast?
Thanks for any help on this. --DD
PS: Great examples in Boost.Beast BTW. Thanks Vinnie. _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users
-- Richard Hodges hodges.r@gmail.com office: +442032898513 home: +376841522 mobile: +376380212