Появилась задача провести стресс тест канала на арендуемом оборудование.
Нужно создать нагрузку на оборудование входящего и исходящего трафика по 1 - 3 Gbps (на данном этапе не важно будет это одно соединение или много)
Удерживать такую нагрузку хотя бы 15 - 25 минут каждый час, в течении 2 недель.
Какие сервисы могут предоставить такую услугу, какой порядок цен?
Есть ли какой то вариант бесплатно это сделать, но не создавая например ноду для TOR, чтобы не получить бан от хостинг провайдера?
Python Script Speedtest-Cli Забанили меня после того как я запустил ~1500 одновременных тестов
iperf как то странно работает
С 1й машины в облаке канал не загрузить, DO нас уже заблокировали как только я организовал трафик более 700mb/s
Попробовал схему 20 машинок в облаке DigitalOcean и по крону запускать
на машинках в облаке
iperf -c DS -b 50M -u -t 1500 -i 1
На сервере iperf запущен так
iperf -s -u -D
Но при 20 машинах доходит только 2-10 mb/s с машины загружая канал на 100-150 mb/s
Хотя загрузить на >700 mb/s мне удалось когда я гнал этот трафик с 1й машины (после чего Support DO заблокировал нам акк)
я так понимаю iperf не способен обрабатывать много подключений. Чем его можно заменить чтобы гнать на сервер с 40 машин хотя бы по 50 mb/s (и обязательно должны быт опция задать bandwish а то опять схлопочу бан от хост провайдера) по 20-25 минут каждый час?
LOIC Я так понимаю будет просто флудить огромным количеством соединений, да и сомнительна легальность этого способа
ipstresstest.com у них Max boot time 1200 Seconds, и как я понял это на весь месяц
IP Stresser (ссылка реферальная) подобный сервис у них максимум час на месяц.
С исходящим пока решил так
nginx на DS (Dedicated server) + файл размером 1GB
на CS (Clouds servers) по крону wget http://DS/bigfile
правда они выкачивают меньше чем за минуту, но больше пока не рискую запускать. Саппорт очень убедительно простит as a reminder we don’t allow any stress testing of any kind on our system.
результат с загрузки с 40 CS iperf+wget
В общем пока у меня мысли такие такие запустить много копий iperf на DS и слушать на разных портах, на каждом CS настроить отправку на свой порт, правда мне надо разворачивать и сворачивать настроенные CS автоматизировано (это я сделал с помощью API), проблема в том что они разворачиваются из 1го образа, вручную все их править не правильно, так что займусь еще освоением ansible.
Еще есть мысли попробовать через netperf, вроде там можно как настроить пропускную способность поэкспериментировав с ключами если верить
Spoiler
From: "Rick Jones" <rick.jones2 at hp.com>
To: "Legend Overfiend" <legendoftheoverfiend at technologist.com>
Subject: Re: [netperf-talk] Any way to limit bandwidth?
Date: Wed, 30 Nov 2005 15:28:04 -0800
>
> Legend Overfiend wrote:
> > Net perf is overwhelming the memory allocation routines of my driver
> > during UDP uplink, but I'd still like to see the maximum performance of
> > my connection. If I could limit the transmit speed to something
> > reasonable, like 8MBps, then I should easily get my results. I don't see
> > this option in the man page. Is it possible?
>
> And what happens when your driver memory allocation routines are
> overwhelmed? I would expect the driver to simply discard the packet
> and move-on, and all should be well.
>
> Anyway, if you configure with the intervals support, you can then
> specify a burst size and inter-burst interval that will have the
> effect of pacing the rate at which data is sent by netperf for UDP.
> I'm ass-u-me-ing that you are using netperf 2.4.X - best to state
> the version
>
> There may be something about intervals support in the manual rather
> than the manpage - look under doc/
>
> happy benchmarking,
>
> rick jones
Thanks, I see that in the manual. I will compile that in.
I was running on OS X and running out of memory buffers. I didn't care about the discarded transmit packets, but for some reason I had no buffers for receive either.
Еще косвенно нашел что Intel® MPI Benchmarks может помочь, но как им пользоваться не нашел.
Все же буду рад дельным предложениям как это можно реализовать еще