Комментарии 12
А ответы от staging сервера как анализируются?
На данный момент есть зачатки статистики, но пока просто вывод в консоль.
В следующей версии планирую значительно улучшить эту часть.
Я решил не включать расширенную статистику в этот релиз, так как эта программа не для нагрузочного тестирования, а повседневного.
В следующей версии планирую значительно улучшить эту часть.
Я решил не включать расширенную статистику в этот релиз, так как эта программа не для нагрузочного тестирования, а повседневного.
Хотя я предвижу что Gor вполне можно будет использовать и для нагрузочного тестирования, особенно если production с большим трафиком.
В консоль выводится html код ответа?
Нет, просто посекундная статистика о количестве запросов, общая и в контексте статус кода. Так будет понятней: github.com/buger/gor/blob/master/replay/request_stats.go#L47
Скрестить бы его с phantomjs.org/ для проверки JS, синтаксиса html и пр. А еще screenshot'ы делать проблемных страниц.
Это все очень здорово звучит, но меня беспокоит работа всего механизма.
Во-первых, необходимо иметь практически полную копию стенда. Необходимо иметь отдельную базу, в которой должны быть такие же данные. Причем, при большой нагрузке данные между production и stagging стендах могут быть неконсистентны. В результате у нас будут валится ошибки на stagging, потому что запросы в production не соответсвуют данным в базе. И мы делаем неверное заблуждение о том, что новая версия пакета готова к выкладке.
Если же делаем slave-реплику базы production в stagging, то мы отсекаем тестирование операций, которые меняют что-то в базе. Опять же, мы не сможем ответить, «А будет ли в production все окей?»
Во-вторых, время такого тестирования большое. Вы по факту никак не управляете нагрузкой в stagging, она такая же как и в production. Траффик довольно сильно прыгает за сутки, сильно прыгает по неделе. Т.е. время тестирования большое. Как минимум это половина для, во время пика траффика и это правда большое количество времени, по сравнению с обычным автоматизированным нагрузочным тестированием. Когда разработчик сделал фичу, протестировал у себя нагрузочно через siege, jmeter, gatling tool и уже имеет полноценное представление о производительности.
В-третьих. И это не говорим о событиях с большими всплесками активности. Вы пиаритесь на хабре, на вашу страницу переходят 10000 уников за первые сутки. Вы выдержете нагрузку? Нельзя сказать пока не появится такой траффик.
В-четвертых. Если новая версия меняет структуру в базе, протестировать на старых запросах не сможем.
Итого: Годится когда можем соблюдать косистентность. Когда нет конкурирующих запросов к базе за одну сущность. Если такие есть, то делаем слейв-реплику и у нас покрыта только часть запросов. Годится когда сервис не большой, и мы можем иметь вторую копию стенда. Годится когда нет резких всплесков активности. Годится когда время тестирования не очень беспокоит. Просто с суточной задержкой раскатываем в production. Годится когда обновления инкрементальные и нет изменений в хендлерах, урлах, запросах сервиса.
Это конечно намного лучше чем ничего, но не заменяет полноценного нагрузочного тестирования. Спасибо большое за статью:)
Во-первых, необходимо иметь практически полную копию стенда. Необходимо иметь отдельную базу, в которой должны быть такие же данные. Причем, при большой нагрузке данные между production и stagging стендах могут быть неконсистентны. В результате у нас будут валится ошибки на stagging, потому что запросы в production не соответсвуют данным в базе. И мы делаем неверное заблуждение о том, что новая версия пакета готова к выкладке.
Если же делаем slave-реплику базы production в stagging, то мы отсекаем тестирование операций, которые меняют что-то в базе. Опять же, мы не сможем ответить, «А будет ли в production все окей?»
Во-вторых, время такого тестирования большое. Вы по факту никак не управляете нагрузкой в stagging, она такая же как и в production. Траффик довольно сильно прыгает за сутки, сильно прыгает по неделе. Т.е. время тестирования большое. Как минимум это половина для, во время пика траффика и это правда большое количество времени, по сравнению с обычным автоматизированным нагрузочным тестированием. Когда разработчик сделал фичу, протестировал у себя нагрузочно через siege, jmeter, gatling tool и уже имеет полноценное представление о производительности.
В-третьих. И это не говорим о событиях с большими всплесками активности. Вы пиаритесь на хабре, на вашу страницу переходят 10000 уников за первые сутки. Вы выдержете нагрузку? Нельзя сказать пока не появится такой траффик.
В-четвертых. Если новая версия меняет структуру в базе, протестировать на старых запросах не сможем.
Итого: Годится когда можем соблюдать косистентность. Когда нет конкурирующих запросов к базе за одну сущность. Если такие есть, то делаем слейв-реплику и у нас покрыта только часть запросов. Годится когда сервис не большой, и мы можем иметь вторую копию стенда. Годится когда нет резких всплесков активности. Годится когда время тестирования не очень беспокоит. Просто с суточной задержкой раскатываем в production. Годится когда обновления инкрементальные и нет изменений в хендлерах, урлах, запросах сервиса.
Это конечно намного лучше чем ничего, но не заменяет полноценного нагрузочного тестирования. Спасибо большое за статью:)
Такие программы как jMeter, httperf or Tsung имеют поддержку log replay, но она либо в зачаточном состоянии либо сфокусированная на нагрузочном тестировании а не эмуляции реальных пользователей. Чувствуете разницу?
Такие инструменты вроде JMeter в первую очередь и предназначены для «эмуляции пользователей». Серьезно, почитайте документации и статьи в сети, там больше слов о создании разных сложных сценариев, нежели о log replay.
Реальные пользователе это не только набор запросов, очень важно правильный порядок и время между запросами, различные HTTP заголовки и так далее.
Опять же, нет никакой проблемы записать access.log с сервера и при необходимости всем таким траффиком протестировать новую версию сервиса. Можно сохранить и порядок, и интервалы между запросами, и даже хидеры если это реально необходимо.
Для нагрузочного тестирования это порой не важно, но для поиска ошибок это критично. К тому же эти средства сложны в настройке и автоматизации.
Мне очень жаль что у вас сложилось такое впечатление:( У нагрузочного тестирования много целей, и это как раз одна из самых важных.
Такие инструменты вроде JMeter в первую очередь и предназначены для «эмуляции пользователей». Серьезно, почитайте документации и статьи в сети, там больше слов о создании разных сложных сценариев, нежели о log replay.
Реальные пользователе это не только набор запросов, очень важно правильный порядок и время между запросами, различные HTTP заголовки и так далее.
Опять же, нет никакой проблемы записать access.log с сервера и при необходимости всем таким траффиком протестировать новую версию сервиса. Можно сохранить и порядок, и интервалы между запросами, и даже хидеры если это реально необходимо.
Для нагрузочного тестирования это порой не важно, но для поиска ошибок это критично. К тому же эти средства сложны в настройке и автоматизации.
Мне очень жаль что у вас сложилось такое впечатление:( У нагрузочного тестирования много целей, и это как раз одна из самых важных.
Спасибо за развернутый комментарий.
Да, такая схемя явно подойдет не под любое приложение. Staging действительно должен иметь актуальную версию, а ошибки которые связаны с тем что в базе не найдена запись прийдется обрабатывать (что не так уж и плохо).
Плюс я старался сделать акцент на том что не стоит путать нагрузочное тестирование с повседневным. Load testing не запускается на каждое изменение (обычно), и имеет определенные минусы, о чем упоминается в статье.
Например как выглядит workflow обычно, разработчик делает в своей ветке изменение, заливает его на staging и тестирует руками. Так вот Gor это скорее дополнение к тестированию руками.
Да, такая схемя явно подойдет не под любое приложение. Staging действительно должен иметь актуальную версию, а ошибки которые связаны с тем что в базе не найдена запись прийдется обрабатывать (что не так уж и плохо).
Плюс я старался сделать акцент на том что не стоит путать нагрузочное тестирование с повседневным. Load testing не запускается на каждое изменение (обычно), и имеет определенные минусы, о чем упоминается в статье.
Например как выглядит workflow обычно, разработчик делает в своей ветке изменение, заливает его на staging и тестирует руками. Так вот Gor это скорее дополнение к тестированию руками.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Улучшаем тестирование путем использования реального трафика