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. > > 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 Staff Engineer C++ Alliance hodge...@gmail.com office: +442032898513
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users