Нагрузочный тест c помощью Go

Отличная статья!
Продолжение приветствуется категорически.

Как я понимаю, главная фишка jmeter не в мощности создаваемой нагрузки а в том, что потом можно посмотретьна различные графики по отзывчивости сервиса на разных уровнях нагрузки.
А если вам именно тупая долбилка нужна, возьмите wrk github.com/wg/wrk (мой форк умеет брать список урлов из файла github.com/seriyps/wrk) или httpperf.

А то, что у вас замер времени останавливается до того, как считается BODY ответа это намеренно сделано?

Меня смутило эта ваша любовь к начальному counter`у в значении -1 :)
А так — здорово, рад что сообщество начинает что-то выкладывать на golang, сам уже имею два успешных внедрения на продакшне.

А как организовывали красивый вывод в консоль?

Почему бы не использовать агентов jmeter, если вы проседаете по CPU на одном инстансе jmeter.
Они вполне хорошо справляются с задачей создания распределенной нагрузки с разных узлов.

Кто там говорил что Java быстра?

JMeter падал с OOM на 10 параллельных загрузках 100МБ файла при 3ГБ выделенных для Java и, съедая при этом 100% от обоих ядер.
Написал скрипт на Ruby+EM, который делал 100 таких загрузок параллельно, потреблял 20МБ памяти и 5% процессора. Там, правда всего один файл был строк на 15.

Зафолловил ГитХаб и добавил звездочку проекту:) Отдельное спасибо за пост, на хабре golangовые посты — редкость.
Кстати, как полезная мелочь, скомпилируйте и добавьте релиз для go-meter. Это удобно для тех, у кого Go не установлен и нечем скрмпилировать.

Весьма радует, что вы выбрали и осилили Go для решения данной задачи: код достаточно хорошо работает и решает свои задачи, несмотря на небольшое знание языка. Однако, при этом код изобилует потенциальными проблемами, которые неизбежно будут копировать ваши читатели.
Например, вместо:
func (this *Settings) Load(fileName string) error {
file, e := ioutil.ReadFile(fileName); if e != nil {
return e
}
e = json.Unmarshal(file, this); if e != nil {
return e
}
return nil
}

Лучше пользоваться ридерами — как в случае больших конфигов, так и просто идеологически правильнее:

func (this *Settings) Load(fileName string) (e error) {
var file os.File
if file, e = os.Open(fileName); e != nil {
return
}
defer file.Close()
decoder := json.NewDecoder(file)
e = decoder.Decode(this)
return
}

Плюс много мелких деталей, делающий код лаконичнее: именованный возврат, defer'ы, функции внутри условия.

По возможности, лучше не читать из канала по счётчику: в случае проблем программа может банально зависнуть в ожидании канала. Лучше закрывать каналы в defer'е и принимать содержимое канала через range.

Вы передаёте Status по ссылке и при этом меняете — у вас нет никаких гарантий, что counter на момент прочтения будет читать именно тот Status, который был отправлен.

Вы создаёте очень большой канал: это совершенно лишний расход памяти.

Полностью инициализировать все переменные в структуре не обязательно: по умолчанию они будут созданы нулевыми, в зависимости от типа, т.е. вместо status := &Status{false, false, false, nil, 0, true, nil, nil, nil} можно делать status := &Status{isFinished: true}

Вообще говоря, есть куча мелочей, которые могут значительно ускорить код: один раз создавать http.Request'ы, вместо diff := time.Now().Sub(lastPrint); if diff.Seconds() > 1 { PrintStatus(); } использовать time.Tick в отдельной goroutine'е, использовать ссылки только там, где нужно, оптимизировать выделение памяти внутри циклов, итд…

PS Возможно, под ваши нужды хватило бы функционала Benchmark'ов в testing'е.