Should I change max-concurrent-requests? >> Note: The implementation has changed. You shouldn't use this setting any longer. Leave it commented out

[BrightSilence]

It was communicated in this pinned topic.

The storagenode docker run command has been updated

Please, update your docker run command to the latest version: https://documentation.storj.io/setup/cli/storage-node

[Pac]

Right, but I don’t suppose all SNOs are watching what is going on the forum? If switching to “latest” was of the upmost importance, surely we would have been notified by e-mail?

@Alexey

Not all specify the email since it’s not mandatory, some specify a fake email

Aah right. Well in that case…
In a way these SNOs just wanna be on their own though… all other SNOs could be notified anyway But then I guess some would complain because they don’t want to receive any e-mails…

Oh well. I’ll just subscribe to topics recommended by Alexey:

@Alexey

I would like to recommend to subscribe to the https://forum.storj.io/c/category-announce/8 and https://forum.storj.io/tag/official-changelog to be updated.

Thx!

[Alexey]

@Pac

But then I guess some would complain because they don’t want to receive any e-mails…

Exactly
Maybe forum not so fast way as email, but you have a choice - receive notifications or not.

[SGC]

yeah they really should get better at informing us about such changes in a more direct way that allows the passive SNO’s to not be engaged in the forum…

but i’m sure that will be changed some time…

well then maybe we should get this kind of notifications on the dashboard…

[Sasha]

@BrightSilence

The numbers you showed do not warrant using this setting. Yes, the success percentages go down a little, but the total number of successful transfers is still higher than when you don’t limit it. You’re not gaining anything by limiting it, you’re actually losing business by setting it. This is the case for almost everyone.

Additionally, if too many nodes use this setting and start rejecting transfers it could lead to failed uploads for customers, because not enough pieces are actually accepted. So, not only is it bad for you, it’s bad for customers as well.

Hopefully the known bug about “cancelled upload - error message displayed in the log when the upload wasn’t actually cancelled” is fixed so that SNO’s can identify accurate success rate for uploads.

I think I set this value to something like 40 or 50 when it was initially introduced with a default value of 7, which caused errors. Increase to 40~50 seems I no longer see the error message but also I don’t want to have this unlimited ie 2000 connections etc. This value should be tweaked to cater for the type of hardware SNO is running.

If it’s left commented, is there any logs/monitor to verify what the peak # of connections are for this setting ?

[BrightSilence]

Back then I was using it too. But they still used gRPC at the time, which required the limit to prevent running into issues. Currently transfers use their own dRPC which can handle many more simultaneous transfers without issues. I believe you can monitor these stats. Have a look at this: Guide to debug my storage node, uplink, s3 gateway, satellite

As for the logging issue, it’s in the works, might not be in the next release though. https://github.com/storj/storj/commit/e9dd5b284534962004416e7bc733ddd582b78aef