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
httperf is probably a closed loop - a quick google search says it will be a closed loop only if no timeout is specified. Closed loop will have high latency which in turn will lower the throughput due to longer wait times. In our experiments we do specify a timeout interval - does that make it an open loop? If so, how?
In any case, it might be worth to test it with a UDP based benchmark like iperf or even memcached UDP based clients. (Ask Yuxin about this).
The text was updated successfully, but these errors were encountered:
It seems that when a timeout is specified in httperf it operates in a open-loop manner. This link in httperf mailing list says "just so you know, if you do not specify a timeout you will be operating in a closed-loop rather than an open loop manner."
a timeout is likely to be on the scale of seconds, so even with a timeout set it will still be a mostly closed loop workload---i.e., within one checkpoint interval if the clients send their max number of open requests then they aren't going to send any more even if the system could handle it (but is just slow to respond because of network buffering).
If we use a more intensive web benchmark (eg the php/sql scripts) this should be less of an issue.
httperf
is probably a closed loop - a quick google search says it will be a closed loop only if notimeout
is specified. Closed loop will have high latency which in turn will lower the throughput due to longer wait times. In our experiments we do specify atimeout
interval - does that make it an open loop? If so, how?In any case, it might be worth to test it with a UDP based benchmark like
iperf
or evenmemcached
UDP based clients. (Ask Yuxin about this).The text was updated successfully, but these errors were encountered: