You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the current version, we can set the maximum concurrent call that was called concurrently.
For example:
./gubrak -r 100 -c config.json
This command will do 100 call with 100 concurrent request. So if I set the r param to 1000 then I will make a 1000 call with concurently.
What I proposed is:
How about making maximum call but we can set the maximum concurrent call separately
maybe something like this:
./gubrak -r 1000 -concurent 100 -c config.json
I'll expect this, we made a 1000 call in total, but separated in 10 times (1000/100) or to simplify, it's like doing batching calling 100 call per batch until it reach 1000 as the targeted total call.
The text was updated successfully, but these errors were encountered:
so we can control how many goroutines we will launch and also how many requests we will launch, but not directly related, is that right @bxcodec ?, i think its good.
is the -concurrent flag mandatory? if not, will the -concurrent use the size of request?
Current version:
In the current version, we can set the maximum concurrent call that was called concurrently.
For example:
This command will do 100 call with 100 concurrent request. So if I set the
r
param to 1000 then I will make a 1000 call with concurently.What I proposed is:
How about making maximum call but we can set the maximum concurrent call separately
maybe something like this:
I'll expect this, we made a 1000 call in total, but separated in 10 times (1000/100) or to simplify, it's like doing batching calling 100 call per batch until it reach 1000 as the targeted total call.
The text was updated successfully, but these errors were encountered: