Closed bunnie closed 2 years ago
may want to try running this against a wf200 dev board attached to a raspi to see if the wf200 itself can even hold up against this
Well, it holds up for a couple seconds at least now:
Requests [total, rate, throughput] 100, 50.52, 3.23
Duration [total, attack, wait] 12.085s, 1.979s, 10.106s
Latencies [min, mean, 50, 90, 95, 99, max] 128.927ms, 6.069s, 5.505s, 9.612s, 10.17s, 10.729s, 10.776s
Bytes In [total, mean] 2028, 20.28
Bytes Out [total, mean] 0, 0.00
Success [ratio] 39.00%
Status Codes [code:count] 0:61 200:39
Error Set:
Get "http://10.0.245.184": dial tcp 0.0.0.0:0->10.0.245.184:80: connect: connection refused
longer runs actually take out the wifi router, and I have to reboot it, so there's multiple weak spots in this chain.
More importantly, the log messages seem to show that by and large the backoff and failsafe mechanisms are working. Eventually things topple over because enough server queues get backed up that something breaks but you have to get a run to go at it stably for about a minute for that to happen. i think it's fine?
Use Vegeta:
echo "GET http://192.168.1.157/" | vegeta attack -duration=1m | tee results.bin | vegeta report
withnet server
runningshould result in WfxErr from WF200 + EC reboot