-
Notifications
You must be signed in to change notification settings - Fork 160
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
curious about the "total success" #410
Comments
@lesismal can u pls help check this again? it doesnt show up like yours. using ubuntu 22.04 golang 1.22 for the for loop, is there a better way to simulate it? i mean what's a proper way to "benchmark" this for production stress test? server
client
|
@lesismal this is my output
|
For Echo benchmark, the client has had resend-logic here in my examples: g.OnData(tls.WrapData(func(c *nbio.Conn, tlsConn *tls.Conn, data []byte) {
if bytes.Equal(wbuf, data) {
tlsConn.Write(wbuf)
atomic.AddInt64(&qps, 1)
} else {
c.Close()
}
})) That means when the client recv 1 message, it will send another message to the server. For more tests, you can implement it yourself. |
please print the closed err and check why it was closed. |
I see there're two connections OnOpen and OnClose logs, are you using the client and server in the same process and using the same Engine? |
@lesismal both client and server are in two different folders like your example, i just replaced/modify the code and run go build that's all. let me check why it's closed... |
@lesismal
|
please just try nbio-examples/tls origin code, don't modify it and see whether it works. |
@lesismal u are right, my bad. let me check what's wrong. thx |
@lesismal i think i discovered a bug. high volumetric for loop sending, bytes.Equal(wbuf,data) <-- this line failed? not sure. can u help test?
|
I ran it on ubuntu and reproduced the problem. Now I make a commit to add data flow control for the nbio.Conn flush, and it works fine on my ubuntu now. go get -u github.com/lesismal/nbio@575223a3921b8c2b2359cdb5d205a11686380a66 Thanks a lot Bro! |
But please notice that we should still avoid such a lot of writing in production env. |
@lesismal i did this: and the program still shows:
need the ability to handle ddos. i do have certain protection / rate limit on my side but... can this be pushed further? i mean actually it shouldnt break right? i havent come across a tcp connection that can break this way though. i'm not sure about other implementation but instead of breaking, it should slow down or something. but i'm sure it shouldnt break. can u think of a better way to fix this? i just tried to do mutex over the iterations but it still breaks. can u think of a way to fix this? client to connection break if there are great number of tlsConn.Write? please provide a workaround of sorts. thx |
@lesismal the code here that crashed. it's funny that when i do a single for loop run and commented out the "
section, it works. but if i just run the whole program in its entirety, it crashed.
|
try this commit: go get -u github.com/lesismal/nbio@a768b89 I optimized nbio.Conn write cache to reduce the num of small buffers cached by nbio.Conn and make it faster when calling writev. |
@lesismal updated. tested, its still not working.
|
Did you updated nbio version for both server and client? |
@lesismal it's working now. thx. can u do a page and ask for people to submit use case as case studies? just curious who will be using it. i still need to test and implement it further. is this used in production? |
for projuct using nbio, can write it here:
yes, in production. but your issue is the first one who write so much data, haha |
it puzzles me why people use non standard lib if it's not using extreme data etc. anyway, i have one last question,
under "high" cpu load, using the standard example of tls, the connection is closed. can you debug this? it seems like a bug to me. otherwise, can you provide update for both server and client to respond to the "dropped" / closed connection? i've tested it and everything is great except this last bit. it's not very assuring if used in production and connection dropped this way. i am wondering how to ensure connectivity or reconnection. please show example of how u would remedy this and think about how to ensure connectivity resilience in future. thx in advance. this should be the last area. it's really great work p.s. : it is still dropping connection sometimes. i think somehow the buf is overwritten or something i'm not sure, it still discon at the byte.Equal area. |
i just checked the production list and the company's site using nbio is not functional anymore, network crashed due to high load? #128 anyway, u can start a new issue page and link that to the readme so as to drive adoption. hope to see this as mainstream for websocket etc. |
I think it's just because nicoroy2561's game app stopped maintenance. It's not because of performance.
Good idea, thank you for your opinion very much! We can see some users here: |
@lesismal pls provide solution for this:
u can run it in multiple client to simulate this issue, it will break connection. after a while under load or something. sometimes doesnt even start. will follow up on this issue tml. thx |
I ran 3 clients, it slow but works. |
btw, the default test using bytes.Equal is just for testing. the tcp/tls transport streaming data, if you write a lot, we may not recv the same size in each OnData callback and the qps may be failed. |
and, you customize the extension/tls, it's an extension but just an example, the implementation of nbhttp and nbhttp/websocket doesn't use it directly but implement features in the similar way. |
I wouldn't provide so much user function customizing help, I'd close this and some other issues. |
tried to write a tls client and testing rps but total success is only around 58000.
ran with default tls server
why?
The text was updated successfully, but these errors were encountered: