[Beast] Slow HTTP connect on Windows. Normal?

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

[Beast] Slow HTTP connect on Windows. Normal?

Boost - Users mailing list
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
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: [Beast] Slow HTTP connect on Windows. Normal?

Boost - Users mailing list
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 <[hidden email]> 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
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users


--
Richard Hodges
Staff Engineer
C++ Alliance
office: +442032898513


_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: [Beast] Slow HTTP connect on Windows. Normal?

Boost - Users mailing list
In reply to this post by Boost - Users mailing list
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 <[hidden email]> 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
office: +442032898513

On Wed, 25 Nov 2020 at 11:55, Dominique Devienne via Boost-users <[hidden email]> 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
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users


--
Richard Hodges
office: +442032898513
home: +376841522
mobile: +376380212


_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: [Beast] Slow HTTP connect on Windows. Normal?

Boost - Users mailing list
In reply to this post by Boost - Users mailing list
On 25/11/2020 10:54, Dominique Devienne via Boost-users 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...

I can confirm that from libcurl wrapping ASIO, initiating a new HTTPS
connection takes almost the same time whether from Linux or Windows.
It's a lot faster than one second as well.

Is it possible that Windows is trying IPv6 first, but there is no IPv6
route?

Niall
_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: [Beast] Slow HTTP connect on Windows. Normal?

Boost - Users mailing list
In reply to this post by Boost - Users mailing list
On Wed, Nov 25, 2020 at 2:55 AM Dominique Devienne via Boost-users
<[hidden email]> wrote:
> 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

This means that the server closed the connection. Are you setting
HTTP/1.1 in the request? For HTTP/1.1 the default is to enable
keep-alive. But for 1.0 the default is to close the connection. It
sounds like your connection is being closed after one request. Beast
definitely supports keep-alive, so this is certainly user error.
Please inspect the request/response messages taking place and post
them on the list unmodified (use a wire sniffer for this if necessary)
if you are still having problems.

Thanks
_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Fwd: [Beast] Slow HTTP connect on Windows. Normal?

Boost - Users mailing list
Oops, this was meant for the list of course. --DD

---------- Forwarded message ---------
From: Dominique Devienne <[hidden email]>
Date: Fri, Dec 11, 2020 at 6:54 PM
Subject: Re: [Boost-users] [Beast] Slow HTTP connect on Windows. Normal?
To: Vinnie Falco <[hidden email]>


On Wed, Nov 25, 2020 at 7:43 PM Vinnie Falco <[hidden email]> wrote:
On Wed, Nov 25, 2020 at 2:55 AM Dominique Devienne via Boost-users
<[hidden email]> wrote:
> 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

This means that the server closed the connection. Are you setting
HTTP/1.1 in the request? For HTTP/1.1 the default is to enable
keep-alive. But for 1.0 the default is to close the connection.

Sorry for the delay. Just getting back to this.
Yes, I'm in 1.1, and I verified that the request has Keep-Alive,
and I'm (or the example, I don't recall) is setting the same value on the response.
 
it sounds like your connection is being closed after one request. Beast
definitely supports keep-alive, so this is certainly user error.
Please inspect the request/response messages taking place and post
them on the list unmodified (use a wire sniffer for this if necessary)
if you are still having problems.

Debugging this, I can see that the close arg to on_write is true, despite the Keep-Alive on the response.
That response has an empty_body BTW, in case it matters. This route just replies 200 OK or 403 Forbidden,
there's no body to return, only the headers matter to the client.

The reason why the connection is closed after the 1st request seems to be because of need_eof().
The async server example has something like this in `send()`:

    template <typename RES>
    void send(RES&& msg) {
        // The lifetime of the message has to extend
        // for the duration of the async operation so
        // we use a shared_ptr to manage it.
        auto sp = std::make_shared<RES>(std::move(msg));

        // Store a type-erased version of the shared
        // pointer in the class to keep it alive.
        res_ = sp;

        bool need_eof = sp->need_eof();
        ctx_.out() << "send: sp->need_eof() = " << need_eof << std::endl;

        // Write the response
        http::async_write(
            stream_, *sp,
            beast::bind_front_handler(
                &session::on_write,
                shared_from_this(),
                sp->need_eof()
            )
        );
    }

And `need_eof()` is true indeed. Which thus calls `on_write()` with `bool close = true`,
resulting in a `do_close()` instead of waiting for the next request:

      void on_write(
        bool close,
        beast::error_code ec,
        std::size_t bytes_transferred
    ) {
        boost::ignore_unused(bytes_transferred);

        if (ec) {
            return; // fail(ec, "write");
        }

        if (close) {
            // This means we should close the connection, usually because
            // the response indicated the "Connection: close" semantic.
            ctx_.out() << "on_write: close()" << std::endl;
            return do_close();
        }

        // We're done with the response so delete it
        res_.reset();

        // Read another request
        do_read();
    }

I stepped into `need_eof()`, and all conditions of the `if` are false, resulting in the `return true` at the end.

template<bool isRequest, class Body, class Fields>
bool
message<isRequest, Body, Fields>::
need_eof(std::false_type) const
{
    // VFALCO Do we need a way to let the caller say "the body is intentionally skipped"?
    if( this->result() == status::no_content ||
        this->result() == status::not_modified ||
        to_status_class(this->result()) ==
            status_class::informational ||
        has_content_length() ||
        chunked())
        return ! keep_alive();
    return true;
}

So is the issue having an empty_body? I'm not supposed to have one on a GET?

BTW, I tried commenting out the `do_close()` inside `on_write()`, just to see what happens,
and it still doesn't work, with the same error, but an additional delay (timeout?) I think.

Here's the response I'm sending:

                ctx_.out() << "Sending response: 200 OK" << std::endl;
                http::response<http::empty_body> res{http::status::ok, req_.version()};
                res.set(http::field::server, BOOST_BEAST_VERSION_STRING);
                res.keep_alive(req_.keep_alive());
                ctx_.out() << "on_read: res.keep_alive() = " << res.keep_alive() << std::endl;
                return send(std::move(res));

I'm fairly sure it's user-error, but it's not easy to figure out for a Beast novice like myself. --DD
 

_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: [Beast] Slow HTTP connect on Windows. Normal?

Boost - Users mailing list
> I'm fairly sure it's user-error, but it's not easy to figure out for a Beast novice like myself. --DD

Your response is 200 OK, but you aren't setting Content-Length: 0.
Under HTTP rules this means that the end of the body is indicated by
an end of file. The documentation for need_eof explains this:

<https://www.boost.org/doc/libs/1_74_0/libs/beast/doc/html/beast/ref/boost__beast__http__message/need_eof.html>

See: "* has_content_length would return true."

For your message, has_content_length() would return false (since you
aren't setting it). Try adding:

    res.content_length( 0 );

or

    res.prepare_payload();

Thanks
_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: [Beast] Slow HTTP connect on Windows. Normal?

Boost - Users mailing list
On Fri, Dec 11, 2020 at 8:15 PM Vinnie Falco <[hidden email]> wrote:
> I'm fairly sure it's user-error, but it's not easy to figure out for a Beast novice like myself. --DD

Your response is 200 OK, but you aren't setting Content-Length: 0.

Well, I did that on purpose :). I thought `http::response<http::empty_body>` implied the zero Content-Length...
 
For your message, has_content_length() would return false (since you aren't setting it). Try adding:
    res.content_length( 0 );

Works!
 
or
    res.prepare_payload();

Works as well.
 
Thanks

Thank you Vinnie! One less thing to worry about this week-end, thanks again. --DD 

_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: [Beast] Slow HTTP connect on Windows. Normal?

Boost - Users mailing list
In reply to this post by Boost - Users mailing list
On Wed, Nov 25, 2020 at 6:46 PM Niall Douglas via Boost-users <[hidden email]> wrote:
On 25/11/2020 10:54, Dominique Devienne via Boost-users wrote:
> 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:38.506180 Connected in 1.023s
>
> While the same on Linux (RH7.5) is just over 2ms:
> 2020-11-25T09:45:45.517550 Connected in 0.000s
>
> That's a huge difference! Almost 500x...

I can confirm that from libcurl wrapping ASIO, initiating a new HTTPS
connection takes almost the same time whether from Linux or Windows.
int main(int argc, char* argv[])
{
    // Check command line arguments.
    if (argc != 5)
    {
        std::cerr << [...]
            "    http-server-async 0.0.0.0 8080 . 1\n";
        return EXIT_FAILURE;
    }
    auto const address = net::ip::make_address(argv[1]);
[...]
    net::io_context ioc{threads};

    // Create and launch a listening port
    std::make_shared<listener>(
        ioc,
        tcp::endpoint{address, port},
        doc_root)->run();
[...]
    return EXIT_SUCCESS; 
} 
Niall
_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users

_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: [Beast] Slow HTTP connect on Windows. Normal?

Boost - Users mailing list
(Sorry, incomplete email; CTRL+Return didn't do what I was expecting...)

On Mon, Dec 14, 2020 at 7:10 PM Dominique Devienne <[hidden email]> wrote:
On Wed, Nov 25, 2020 at 6:46 PM Niall Douglas via Boost-users <[hidden email]> wrote:
On 25/11/2020 10:54, Dominique Devienne via Boost-users wrote:
> 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:38.506180 Connected in 1.023s
>
> While the same on Linux (RH7.5) is just over 2ms:
> 2020-11-25T09:45:45.517550 Connected in 0.000s
>
> That's a huge difference! Almost 500x...

I can confirm that from libcurl wrapping ASIO, initiating a new HTTPS
connection takes almost the same time whether from Linux or Windows.

I finally figured this out, mostly by chance...

As the extract below shows, Beast's example uses tcp::endpoint{net::ip::make_address("0.0.0.0"), port}
in its sample usage, and I had copy/pasted that in my code (using "0.0.0.0"). This works, in that the server
starts fine, and clients work fine too, but leads to those > 1,000ms client connection times on Windows.
While using e.g. tcp::endpoint{ tcp::v6(), port } results in 20-30ms connection times on Windows. (2-3ms on Linux).

So user error again. But maybe that usage example should use something else?
I guess taking an explicit IP is in case the server has multiple network interfaces / IPs?
Not sure what could replace it, to save the next poor soul from making the same mistake I did. --DD

PS: Niall, I've still seeing 10x between Win10 and RH7, but that's better than 500x, and that's w/o SSL.
  Even with the server on Win10, and the client on Linux, it's still 3ms. So it's the Win10 client that's slow somehow I guess.
int main(int argc, char* argv[])
{
    // Check command line arguments.
    if (argc != 5)
    {
        std::cerr << [...]
            "    http-server-async 0.0.0.0 8080 . 1\n";
        return EXIT_FAILURE;
    }
    auto const address = net::ip::make_address(argv[1]);
[...]
    net::io_context ioc{threads};

    // Create and launch a listening port
    std::make_shared<listener>(
        ioc,
        tcp::endpoint{address, port},
        doc_root)->run();
[...]
    return EXIT_SUCCESS;
} 

_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: [Beast] Slow HTTP connect on Windows. Normal?

Boost - Users mailing list
On 14/12/2020 18:27, Dominique Devienne via Boost-users wrote:

> I finally figured this out, mostly by chance...
>
> As the extract below shows, Beast's example uses
> tcp::endpoint{net::ip::make_address("0.0.0.0"), port}
> in its sample usage, and I had copy/pasted that in my code (using
> "0.0.0.0"). This works, in that the server
> starts fine, and clients work fine too, but leads to those > 1,000ms
> client connection times on Windows.

Now you describe this, this is familiar. Windows has always done this.
Sorry I didn't think of it sooner.

> While using e.g. tcp::endpoint{ tcp::v6(), port } results in 20-30ms
> connection times on Windows. (2-3ms on Linux).

If you're on loopback and you'd like to close that gap, you need to turn
on SIO_LOOPBACK_FASTPATH. I've no idea if ASIO can do that for you, I'm
still on a pre-churn ASIO. An alternative is to bind to a real NIC, and
not go via loopback.

If you're on a real NIC over a real network, I find a 20-30ms connection
time abnormal. Windows 10 has a fast TCP stack, compared to previous
Windows. It should be single digit milliseconds.

Niall
_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: [Beast] Slow HTTP connect on Windows. Normal?

Boost - Users mailing list
On Mon, Dec 14, 2020 at 7:42 PM Niall Douglas via Boost-users <[hidden email]> wrote:
> While using e.g. tcp::endpoint{ tcp::v6(), port } results in 20-30ms
> connection times on Windows. (2-3ms on Linux).

If you're on loopback and you'd like to close that gap, you need to turn
on SIO_LOOPBACK_FASTPATH. I've no idea if ASIO can do that for you, I'm
still on a pre-churn ASIO. An alternative is to bind to a real NIC, and
not go via loopback.

No sure to follow. Loopback only allows local (same host) connection, no? 
What do you mean bind to a real NIC? That actual DHCP allocation IP?

If you're on a real NIC over a real network, I find a 20-30ms connection
time abnormal. Windows 10 has a fast TCP stack, compared to previous
Windows. It should be single digit milliseconds.

Yes to both. Not sure how to diagnose this further though. --DD 

_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: [Beast] Slow HTTP connect on Windows. Normal?

Boost - Users mailing list
In reply to this post by Boost - Users mailing list



If you're on loopback and you'd like to close that gap, you need to turn
on SIO_LOOPBACK_FASTPATH. I've no idea if ASIO can do that for you, I'm
still on a pre-churn ASIO. An alternative is to bind to a real NIC, and
not go via loopback.


You can set any option you want on the underlying socket with socket::native_handle()

 
--
Richard Hodges
office: +442032898513
home: +376841522
mobile: +376380212


_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users