Limitation on open connections

[Bizilizi]

I am using Bitcoin Cash node based on Bitcoin Unlimited to serve requests from my web service. I have decided to do stress test of node and investigated some strange behavior.

• Warning: Reducing -maxconnections from 20000 to 873, because of system limitations. Can you please explain this more in detail.
• Node process easily up to 4000 simultaneous requests for 2 seconds , but after increasing this number to 5000 , required time suddenly blows up to 33 seconds and then basically have linear grow with respect to linear grow of requests number. Can you please explain your approach for the asynchronous processing of RPC requests.

Basically I want to understand how can I horizontally scale system based on Bitcoin Unlimited

[ptschip]

On 02/02/2019 2:12 a.m., Bizilizi wrote: I am using Bitcoin Cash node based on Bitcoin Unlimited to serve requests from my web service. I have decided to do stress test of node and investigated some strange behavior. * Warning: Reducing -maxconnections from 20000 to 873, because of system limitations. Can you please explain this more in detail.

This is caused because there are OS limitations and also a hard limit in the code of 1024 in the size of the fdset. This means only that many connections can be handled, but it may be futher limited depending on OS.  Until we move away from using select() in our sockest to poll() this is not going to change, but that will not be happening soon.

* Node process easily up to 4000 simultaneous requests for 2 seconds , but after increasing this number to 5000 , required time suddenly blows up to 33 seconds and then basically have linear grow with respect to linear grow of requests number. Can you please explain your approach for the asynchronous processing of RPC requests.

I'm not sure what kind of test your doing here, I assume it's just a sudden burst of 5000 tx's?  If so I'm not surprised that the sytem slows down.  There are couple of buffers that would overflow here and possibly be the cause of the slowdown. As long as the app can recover under this kind of severe stress then that's a good test in my view.  I would expect some kind of reduced performance for a short period of time.  That said, there may still be other performance issues that can be tuned in the app but we haven't gotten to another round of giga-net testing for a while.  Unofficially though we've done 14,000 tx per second...but that's per second, not all at once.

Basically I want to understand how can I horizontally scale system based on Bitcoin Unlimited

If you want to scale more you need more CPU's to allow for more message process threads...you can also up the number of message process threads, which is defaulted to 1/2 the number of cpu's, if you want to. use the following config settings to get more or less threads:

…

-net.msgHandlerThreads=<num>

-net.msgAdmissionThreads=<num> you may also want to increase the size of your send/receive buffers although if your running the dev branch they are already at 10MB each...

-maxreceivebuffer=10000

-maxsendbuffer=10000

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1587>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AMRF0AJL7etzNuSDHN7KgTGM4HVu1n4qks5vJWSYgaJpZM4afhiZ>.