Fix the threadPoolSize not working.

[iteyelmp]

ethstorage/ethstorage-sdk#17 (comment)
#15 (review)

Fix the bug where the threadPoolSize parameter has no effect. The issue is caused by the parameter being passed as a string, which fails to be recognized correctly. As a result, the concurrency level defaults to the maximum, causing -6 and -12 to produce the same outcome.

After fixing the issue, the -s parameter will properly reflect the specified concurrency level, resulting in a noticeable difference in execution time.

For example:
Download the repository from https://github.com/vbuterin/blog, and then upload the site folder. After uploading all the files, perform the upload operation again. This second operation will only compare all files and will not trigger an actual upload. The time taken is as follows:

-s 15: 2.4 minutes,
-s 6: 4.7 minutes.
default is 6: 4.66 minutes.

[qzhodl]

As a good PR practice, providing clear comments is crucial. You should not assume that the reviewer has the full context of the issue (in fact, DL does not have context for this issue). Therefore, it is essential to include:

• A link to the reported issue
• An analysis of the root cause
• A description of how you tested the fix
• The results of your testing

[qzhodl]

ethstorage/ethstorage-sdk#17 (comment) #15 (review)

Fix the bug where the threadPoolSize parameter has no effect. The issue is caused by the parameter being passed as a string, which fails to be recognized correctly. As a result, the concurrency level defaults to the maximum, causing -6 and -12 to produce the same outcome.

After fixing the issue, the -s parameter will properly reflect the specified concurrency level, resulting in a noticeable difference in execution time.

For example: Download the repository from https://github.com/vbuterin/blog, and then upload the site folder. After uploading all the files, perform the upload operation again. This second operation will only compare all files and will not trigger an actual upload. The time taken is as follows:

-s 15: 2.4 minutes, -s 6: 4.7 minutes.

I believe your test plan should at least cover the scenario described in the reported issue: ensuring that the time cost is the same when using the default threadPoolSize versus -s 6