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 <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...)

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