var uuidV4 = require('uuid/v4');
var gor = require("goreplay_middleware");
gor.init()
gor.on('request', function(req) {
req.http = gor.setHttpHeader(req.http, "X-Request-ID", uuidV4());
return req;
})
Главный плюс GoReplay в данном случае что это не прокси, он просто анализирует входящий траффик. Не нужно беспокоится что из-за ошибки в прокси будут проблемы у бользователя. Но nginx в этом плане конечно очень надежный.
Ну и конечно GoReplay также может записывать и ответы сервера, и при их проигрывании на другую среду, можно сравнивать ответы оригильные и новые.
У нас немного другая нагрузка, но результат тестирования схожий. Еще много проблем с индексами, строятся гораздо медленнее, и пару раз попадали на segfaults при их постройке. При подаче багрепорта, ответили только через неделю…
Ну при большой нагрузке тут явно будут проблемы. Так допустим счетчик opencntr не будет работать как надо, он не thread-safe. Либо используйте mutex либо sync/atomic, еще лучше на channels переписать. Но как я уже сказал на небольшой нагрузке эти проблемы не будут заметны.
UPD: не заметил комментарий что цель считать примерно
Тут варианта два:
1) Индексации AJAX интерфейсов (если страницу запрашивает бот, система отдает ему HTML отрендеренный в PhanotmJS).
2) Или для интеграционных тестов.
Да, такая схемя явно подойдет не под любое приложение. Staging действительно должен иметь актуальную версию, а ошибки которые связаны с тем что в базе не найдена запись прийдется обрабатывать (что не так уж и плохо).
Плюс я старался сделать акцент на том что не стоит путать нагрузочное тестирование с повседневным. Load testing не запускается на каждое изменение (обычно), и имеет определенные минусы, о чем упоминается в статье.
Например как выглядит workflow обычно, разработчик делает в своей ветке изменение, заливает его на staging и тестирует руками. Так вот Gor это скорее дополнение к тестированию руками.
Ну формально вам ничего не мешает написать свою небольшую прослойку, которая будет получать трафик от Gor, и запускать эти запросы в phontomjs. Что то типа reverse proxy.
Ну на самом деле они просто выбрали неправильный инструмент. Если нужна производительность то нужно использовать сервера с неблокирующим IO, либо параллелизировать через акторы, нарпимер celluloid.io/. А лучше все вместе. Ну и конечно же jRuby и Rubinius с нормальными threads.
На своем проекте мы используем Goliath и он работает очень шустро.
Я думаю резонный вопрос, почему вы решили реализовать все сами, а не использовать множество из текущий решений вроде Kong или Tyk?
Я автор GoReplay, спасибо за упоминание :)
Да, для вашей цели post_action пожалуй неплохое решение.
Стоит добавить что задача добавления uuid в GoReplay решается довольно просто с помощью middleware https://github.com/buger/goreplay/tree/master/middleware
Например такая NodeJS программа
Главный плюс GoReplay в данном случае что это не прокси, он просто анализирует входящий траффик. Не нужно беспокоится что из-за ошибки в прокси будут проблемы у бользователя. Но nginx в этом плане конечно очень надежный.
Ну и конечно GoReplay также может записывать и ответы сервера, и при их проигрывании на другую среду, можно сравнивать ответы оригильные и новые.
Как то так https://goreplay.org :)
В общем очень сыро, и с поддержкой пока не очень.
и картидж с BASIC
blog.golang.org/race-detector
UPD: не заметил комментарий что цель считать примерно
1) Индексации AJAX интерфейсов (если страницу запрашивает бот, система отдает ему HTML отрендеренный в PhanotmJS).
2) Или для интеграционных тестов.
Да, такая схемя явно подойдет не под любое приложение. Staging действительно должен иметь актуальную версию, а ошибки которые связаны с тем что в базе не найдена запись прийдется обрабатывать (что не так уж и плохо).
Плюс я старался сделать акцент на том что не стоит путать нагрузочное тестирование с повседневным. Load testing не запускается на каждое изменение (обычно), и имеет определенные минусы, о чем упоминается в статье.
Например как выглядит workflow обычно, разработчик делает в своей ветке изменение, заливает его на staging и тестирует руками. Так вот Gor это скорее дополнение к тестированию руками.
В следующей версии планирую значительно улучшить эту часть.
Я решил не включать расширенную статистику в этот релиз, так как эта программа не для нагрузочного тестирования, а повседневного.
Ну на самом деле они просто выбрали неправильный инструмент. Если нужна производительность то нужно использовать сервера с неблокирующим IO, либо параллелизировать через акторы, нарпимер celluloid.io/. А лучше все вместе. Ну и конечно же jRuby и Rubinius с нормальными threads.
На своем проекте мы используем Goliath и он работает очень шустро.
Ссылки в тему:
celluloid.io/
github.com/celluloid/reel
goliath.io
github.com/mperham/rack-fiber_pool
jruby.org/
rubini.us/