Should I change max-concurrent-requests? (ERROR piecestore upload rejected, too many requests)

There is not one answer for everyone. If you have low powered hardware, you probably shouldn’t. In worst cases you might want to lower it. But if your hardware is fast and your connection is as well, it could be beneficial to raise this number.

How do I change the setting?

# Maximum number of simultaneous transfers
storage2.max-concurrent-requests: 7

Add these lines at the end of the config.yaml and play with the number a bit. You have to stop the node, make the change, then start the node again.

Why are there larger numbers in the error messages than what is set in the config.yaml?
The node only rejects uploads when the limit is reached, since you don’t want to deny paid download traffic. Additionally there is much more concurrency and overhead in upload traffic, so rejecting isn’t as much of a problem there.

How do I determine what the right setting is?
This really depends on hardware and connection. The biggest bottlenecks are connection speed and IO, but on low RAM devices RAM may play a role as well. It’s also useful to keep in mind your data cap if you have one. You’ll want to balance the rate of accepting transfers against the rate of interrupted transfers because your node was too slow or saturation of system resources. A few of us SNO’s have created a script together in order to monitor the success rates of your node based on the logs. You can find it here. You’re mostly looking to get the acceptance rate for uploads as high as possible, without the success rate for uploads and downloads going down. If your success rate is already low and especially if you have a data cap, it would be interesting to lower the concurrency number to make sure your bandwidth is focused on fewer transfer that will in fact succeed more often. I myself have an uncapped high speed connection with fairly fast hardware and found that 40 is probably a good setting for me, but a friend of mine has the exact opposite. Slow connection, lower powered hardware and a data cap. We are still testing his setup, but he has seen great results by dropping the number to 4 and the success rate has increased, which wastes less bandwidth on interrupted transfers and eventually will be more profitable. I hope this helps a bit. Higher is definitely not always better.