Boost logo

Boost Users :

From: Richard Hodges (hodges.r_at_[hidden])
Date: 2020-11-25 16:31:24


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_at_[hidden]> 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_at_[hidden]
office: +442032898513
On Wed, 25 Nov 2020 at 11:55, Dominique Devienne via Boost-users <
boost-users_at_[hidden]> 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_at_[hidden]
> https://lists.boost.org/mailman/listinfo.cgi/boost-users
>
-- 
Richard Hodges
hodges.r_at_[hidden]
office: +442032898513
home: +376841522
mobile: +376380212


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net