one more question. thx for the prompt reply, how well does it scale as a client?

[ouvaa]

i understand u spend a lot of time on server performance. (so do i) but how's to benchmark client? i would like to test multicore performance of tcp client (specifically with tls).

do u have something to suggest? i hope to see cpu maxed out with tps. how can this be done i wonder.

[lesismal]

Thx for your attention and feedback to nbio!

nbhttp client is blocking mod during dialing/connectx, after dialing, it's non-blocking mod and managed by nbio poller, then it would be the same as the non-blocking mod connections accepted and handled by nbio server.

In my benchmark test, when there are not a huge number of connections and your hardware specifications are good enough, non-bloking mod connections are slower than std connections, but when it's a huge number of connections, compared to std connections, non-blocking mod connections reduce a lot of mem/gc usage and avoid STW. So, it depends on the details of your online service, if the huge number of connections makes the std solution run too bad, nbio may help more. I'd suggest running some tests using some examples from your online services.

[ouvaa]

@lesismal i understand the huge number of connections etc. but let's say it's a proxy between the

[tls nbio client] <-> [tls nbio server (so reuse port)]

only very few connections. ... i've tested the server side and it's great but... i would like to use a so_reuseaddr for testing the tps between nbio server and client. can u help make this an nbio client with so_reuseaddr example?

https://github.com/lesismal/nbio-examples/blob/master/http/client/client.go

thx in advance. basically i'm testing the performance for tps and mem use to replace my network connectivity with tls through nbio

p.s. : i dont really understand this nbio but just wondering if it's still applicable if io_uring is used because u dont seem to suggest io_uring support as roadmap? sry for my newbie question. not very sure about the internals of epoll stuff etc

[lesismal]

you can set nbhttp.Client.Prosy and use it to customize your own dialer. but I think reuseaddr wouldn't help more for HTTP client side.

io_uring may not improve the performance in general scenarios, it may have safety problems and cost more mem, so I haven't spent much time on it, I'm not sure about that. if golang runtime moved forward to io_uring in the future, I may follow it in nbio, else not plan to do that.

[ouvaa]

@lesismal can u still show a snippet of how to do reuseaddr? i'm doing so to help more with the server receiving side as each tcp connector opens up one fd.

iouring does cost more mem but for huge number of connection it's more worth it.

thx anyway, it's great. i'm using cloudwego/netpoll for now and for websocket wise, will definitely use yours. thx

pls show the reuseaddr example with tls with nbio. thx

[lesismal]

Ah sorry, I was wrong that can use nbhttp.Client.Proxy, nbio use std dialer by default and can't customize it by now.

[lesismal]

I'll consider to support a new config field http.Client.Dial to support users to customize it. Then just need to set http.Client.Dial = github.com/libp2p/go-reuseport.Dial/DialTimeout

[lesismal]

now support http.Client.Dial configuration: https://github.com/lesismal/nbio/releases/tag/v1.5.4