Спасибо за статью, может быть пропустил, не увидел как реализована остановка теста? И есть ли остановка по критериям? Выход за допустимое время отклика или по количеству ошибок?
Тоже проходили подобный путь, но пока остались на bash-скриптах+python для формирования отчетов, частично описано в статье https://habr.com/ru/companies/zyfra/articles/757890/ Так же уже сделали сравнение с целевыми показателями по времени отклика и интенсивности
Аналогичное решение отдельного сервиса для конфигурации, запуска и контроля тестов витает в воздухе, но пока обходимся bash-скриптами.
Обычные счетчики с импульсным выходом, фирму не буду называть, их полно, такие есть у каждого производителя и стоят не сильно дороже обычных. Интегрируются в HA через защиту от протечек, это как раз описано в предыдущей статье.
Да, решение интересное и уже обсуждалось выше, к нему на мой взгляд ещё нужно добавить датчик протока, чтобы понимать когда именно нужно сравнивать показания давлений. Но в тоже время система довольна затратная и сложная в установке, при этом судя по комментариям выше, датчики давления быстро выходят из строя.
По поводу забития фильтра после отключения воды согласен, забиться может быстро, но в моем случае воду отключают крайне редко и по результатам нескольких месяцев и нескольких картриджей, заметна корреляция между приближением к максимальному ресурсу и снижением давления.
Идея с двумя датчиками давления очень интересная и по идее должна отображать как раз то что нужно. Но тут вижу проблему, что когда воду закрывают, давление выравнивается, а разница будет только когда водой пользуются. Т.е. большую часть времени давление будет одинаково, нужно ещё ставить какой то датчик протока, чтобы понимать, когда именно нужно мерить давление. Такое решение конечно сложнее будет, но явно точнее.
А можете подробне рассказать про сенсор загрязнения из посудомойки? Получилось не применимо, к этой ситуации?
Согласен, правильнее было назвать статью "контроль ресурса магистральных фильтров", но мне не понравилось, как звучит. Насчёт измерения качества воды тестером, на своей воде пробовал, результаты до и после магистрального фильтра были примерно одинаковые, т.к. он измеряет растворенные соли, а фильтр убирает только механические загрязнения. Но идея с каким то анализом воды очень интересная.
Спасибо! Дельные замечания, update в моем случае реализован только у одного сенсора, но обновляет данные на все устройство, т.е. лишний раз не должен дергаться. Хотя где то в глубине души я предполагал что это как то не правильно, data update coordinator более правильный подход, если руки дойдут, переделаю.
В том то и дело, что даже 20к не получилось. Да конкретный сценарий больше 20к не может выдать, но даже если указать ему не 200, а 2000 или 20000 вюзеров, результат не изменится.
P.S. Полная копия вашего 10-ти минутного теста с закоментированным sleep выдает 45K reqs/s без единой ошибки.
Тут уже вопрос в каком окружении и сколько ресурсов ему для этого понадобилось, у меня все инструменты запускались в одинаковой, ограниченной среде.
Задержки устанавливаются не для искуственного ограничения, а для управляемого и предсказуемого роста нагрузки, все таки это важно при тестировании производительности. Честно сказать, результат K6 меня тоже удивил, возможно у меня были какие то ошибки при его использовании, но пока не понятно какие. В моем случае без задержки K6 быстро съедает все ресурсы виртуалки и начинает вести себя нестабильно, при этом результат не сильно меняется.
Так они же и разделены, генератор нагрузки на виртуалке, тестируемое приложение на хост машине, конечно они могут влиять друг на друга, но и в реальной жизни такое возможно, когда виртуальная машина генератора нагрузки и приложения нарезаны с одной хост-машины. По поводу CPU steal time 95+, моя вина, подложил не очень очевидный график, он показывает значение в стеке и накладывает друг на друга нулевые графики. В реальности steal time максимум 0,782%
Времена отклика в миллисекундах, по поводу увеличения конкурентных сценариев, изначально так и делал, производительность была сильно ниже, но вот про общий пул подключений интересная идея, думаю должно помочь, спасибо!
Спасибо за статью, может быть пропустил, не увидел как реализована остановка теста? И есть ли остановка по критериям? Выход за допустимое время отклика или по количеству ошибок?
Спасибо за статью, интересное решение.
Тоже проходили подобный путь, но пока остались на bash-скриптах+python для формирования отчетов, частично описано в статье https://habr.com/ru/companies/zyfra/articles/757890/
Так же уже сделали сравнение с целевыми показателями по времени отклика и интенсивности
Аналогичное решение отдельного сервиса для конфигурации, запуска и контроля тестов витает в воздухе, но пока обходимся bash-скриптами.
Обычные счетчики с импульсным выходом, фирму не буду называть, их полно, такие есть у каждого производителя и стоят не сильно дороже обычных. Интегрируются в HA через защиту от протечек, это как раз описано в предыдущей статье.
Да, решение интересное и уже обсуждалось выше, к нему на мой взгляд ещё нужно добавить датчик протока, чтобы понимать когда именно нужно сравнивать показания давлений. Но в тоже время система довольна затратная и сложная в установке, при этом судя по комментариям выше, датчики давления быстро выходят из строя.
По поводу забития фильтра после отключения воды согласен, забиться может быстро, но в моем случае воду отключают крайне редко и по результатам нескольких месяцев и нескольких картриджей, заметна корреляция между приближением к максимальному ресурсу и снижением давления.
Идея с двумя датчиками давления очень интересная и по идее должна отображать как раз то что нужно. Но тут вижу проблему, что когда воду закрывают, давление выравнивается, а разница будет только когда водой пользуются. Т.е. большую часть времени давление будет одинаково, нужно ещё ставить какой то датчик протока, чтобы понимать, когда именно нужно мерить давление. Такое решение конечно сложнее будет, но явно точнее.
А можете подробне рассказать про сенсор загрязнения из посудомойки? Получилось не применимо, к этой ситуации?
Согласен, правильнее было назвать статью "контроль ресурса магистральных фильтров", но мне не понравилось, как звучит. Насчёт измерения качества воды тестером, на своей воде пробовал, результаты до и после магистрального фильтра были примерно одинаковые, т.к. он измеряет растворенные соли, а фильтр убирает только механические загрязнения. Но идея с каким то анализом воды очень интересная.
Спасибо! Дельные замечания, update в моем случае реализован только у одного сенсора, но обновляет данные на все устройство, т.е. лишний раз не должен дергаться. Хотя где то в глубине души я предполагал что это как то не правильно, data update coordinator более правильный подход, если руки дойдут, переделаю.
В том то и дело, что даже 20к не получилось. Да конкретный сценарий больше 20к не может выдать, но даже если указать ему не 200, а 2000 или 20000 вюзеров, результат не изменится.
Тут уже вопрос в каком окружении и сколько ресурсов ему для этого понадобилось, у меня все инструменты запускались в одинаковой, ограниченной среде.
Задержки устанавливаются не для искуственного ограничения, а для управляемого и предсказуемого роста нагрузки, все таки это важно при тестировании производительности. Честно сказать, результат K6 меня тоже удивил, возможно у меня были какие то ошибки при его использовании, но пока не понятно какие. В моем случае без задержки K6 быстро съедает все ресурсы виртуалки и начинает вести себя нестабильно, при этом результат не сильно меняется.
Спасибо! По-возможности попробую.
Так они же и разделены, генератор нагрузки на виртуалке, тестируемое приложение на хост машине, конечно они могут влиять друг на друга, но и в реальной жизни такое возможно, когда виртуальная машина генератора нагрузки и приложения нарезаны с одной хост-машины. По поводу CPU steal time 95+, моя вина, подложил не очень очевидный график, он показывает значение в стеке и накладывает друг на друга нулевые графики. В реальности steal time максимум 0,782%
Времена отклика в миллисекундах, по поводу увеличения конкурентных сценариев, изначально так и делал, производительность была сильно ниже, но вот про общий пул подключений интересная идея, думаю должно помочь, спасибо!