Investigate C# node issues in RATE mode with 50+ QPS #4

New issue

Closed

opened 2025-12-28 18:11:50 +00:00 by sami · 2 comments

sami commented

2025-12-28 18:11:50 +00:00

Owner

Originally created by @roman-khimov on GitHub (Aug 26, 2020).

Originally assigned to: @AnnaShaleva on GitHub.

It should work, I think. And it shouldn't be the same problem as in #22 (though let's see if it changes anything). So something's wrong and we need to find out what exactly.

Originally created by @roman-khimov on GitHub (Aug 26, 2020). Originally assigned to: @AnnaShaleva on GitHub. It should work, I think. And it shouldn't be the same problem as in #22 (though let's see if it changes anything). So something's wrong and we need to find out what exactly.

sami closed this issue

2025-12-28 18:11:50 +00:00

sami commented

2025-12-28 18:11:50 +00:00

Author

Owner

@AnnaShaleva commented on GitHub (Aug 27, 2020):

Partly this problem connected with #22. Increasing the number of MaxConcurrentConnections up to 200 makes it possible for C# single-node to handle 50 and 60 QPS and to get pretty stable results. The results with MaxConcurrentConnections=300 are almost the same as for Go single-node: 47.961 tx/s for 50 QPS and 58.162 for 60 QPS.

Increasing the MaxConcurrentConnections up to 400/500/1000 does not give results for 300 and 1000 QPS single-node consensus tests. I get the same error in this case: could not fetch block count: error after calling rpc server dialing to the given TCP address timed out.

For 4-nodes consensus test with MaxConcurrentConnections=300 the results are not so stable (sometimes I still encounter the same problem). But I managed to get the following results: 37.525 tx/s for 50 QPS and 30.767 for 60 QPS.

@AnnaShaleva commented on GitHub (Aug 27, 2020): Partly this problem connected with #22. Increasing the number of `MaxConcurrentConnections` up to 200 makes it possible for C# single-node to handle 50 and 60 QPS and to get pretty stable results. The results with `MaxConcurrentConnections=300` are almost the same as for Go single-node: 47.961 tx/s for 50 QPS and 58.162 for 60 QPS. Increasing the MaxConcurrentConnections up to 400/500/1000 does not give results for 300 and 1000 QPS single-node consensus tests. I get the same error in this case: `could not fetch block count: error after calling rpc server dialing to the given TCP address timed out`. For 4-nodes consensus test with `MaxConcurrentConnections=300` the results are not so stable (sometimes I still encounter the same problem). But I managed to get the following results: 37.525 tx/s for 50 QPS and 30.767 for 60 QPS.

sami commented

2025-12-28 18:11:51 +00:00

Author

Owner

@roman-khimov commented on GitHub (Aug 27, 2020):

That's very strange as it just shouldn't have any relation to #22. We need to ensure first that we really have only one connection with this setup.

@roman-khimov commented on GitHub (Aug 27, 2020): That's very strange as it just shouldn't have any relation to #22. We need to ensure first that we really have only one connection with this setup.

sami referenced this issue

2025-12-28 18:11:51 +00:00

Provide a set of make targets for standard runs with proper dependencies #9

sami referenced this issue

2025-12-28 18:11:56 +00:00

Improve benchmark usability #18