Комментарии 6
«Continuous Intergation»
А специально в названии в слове Intergation буквы поменяли местами с gr на rg? Или это новый термин в компании?
А специально в названии в слове Intergation буквы поменяли местами с gr на rg? Или это новый термин в компании?
Круто. Но возникает несколько вопросов:
- Я правильно понимаю, что вся эта машина заводится на каждый коммит?
- А сколько стоит такое удовольствие по времени и железу? В длительности одного цикла CI — интуитивно кажется, что 95% времени занимает именно тестирование производительности. И в железе — если обычный цикл CI обходится билд-агентом, то здесь уже нужно целое тестовое окружение, которое при этом утилизирует ресурсы виртуалки под 100%
- Я правильно понимаю, что конфигурация железа не обязана походить на боевую, так как нам важно лишь заметить проседание производительности относительно предыдущих коммитов?
- Если тестируемому сервису нужно сходить в другие сервисы, то вы их мокаете, или реально воспроизводите весь контур?
- Есть ли у менеджера проекта опция «записать просадку производительности в техдолг, но выпустить суперважную фичу прямо сейчас»?
1. Не совсем на каждый, через небольшой интервал. Всё таки коммитов много, а весь граф тестов не легкий. Но при этом система CI всегда находит коммит, который внес значительное изменение.
2. У нас большую часть времени в цикле занимает подготовка индексов, на которых работает сервис. Но это наша специфика. Они занимают терабайты суммарно и строятся из нескольких источников. Если говорить про тесты, которые измеряют RPS, то они занимают час каждая итерация, которые проводятся параллельно. Если про железо. Нужна возможность запустить эту часть CI на отдельной «чистой» машине, чтобы измерения были правильными. В нашей системе запуска такая возможность есть, мы указываем необходимую нам конфигурацию хоста, выбирается подходящий и тест на хосте работает один. Мы не делаем отдельное тестовое окружение, но да, на час машина занята только 1 тестом.
3. Правильно, у нас разные машины на проде и на тестах.
4. Мокаем. Поднять все сервисы, значит по сути провести интеграционное тестирование. Это не то, что мы тут хотим. Данные для мока мы готовим заранее из логов в продакшене.
5. В основном нет. Если это не предусмотрено изначально, мы такие коммиты в прод не пускаем. А ещё мы все фичи выпускаем с возможностью их быстрого выключения, так что, если в продакшене какое-то включение неожиданно дает дополнительную нагрузку, то мы быстро фичу вырубаем.
2. У нас большую часть времени в цикле занимает подготовка индексов, на которых работает сервис. Но это наша специфика. Они занимают терабайты суммарно и строятся из нескольких источников. Если говорить про тесты, которые измеряют RPS, то они занимают час каждая итерация, которые проводятся параллельно. Если про железо. Нужна возможность запустить эту часть CI на отдельной «чистой» машине, чтобы измерения были правильными. В нашей системе запуска такая возможность есть, мы указываем необходимую нам конфигурацию хоста, выбирается подходящий и тест на хосте работает один. Мы не делаем отдельное тестовое окружение, но да, на час машина занята только 1 тестом.
3. Правильно, у нас разные машины на проде и на тестах.
4. Мокаем. Поднять все сервисы, значит по сути провести интеграционное тестирование. Это не то, что мы тут хотим. Данные для мока мы готовим заранее из логов в продакшене.
5. В основном нет. Если это не предусмотрено изначально, мы такие коммиты в прод не пускаем. А ещё мы все фичи выпускаем с возможностью их быстрого выключения, так что, если в продакшене какое-то включение неожиданно дает дополнительную нагрузку, то мы быстро фичу вырубаем.
А моки отвечают мгновенно или с рандомной задержкой?
Просто иногда бывают сервисы, которым нужно много ходить в другие сервисы и когда мы меряем время ответа, то наверное хочется учесть и штрафы за обращение в другой сервис. Как решается этот вопрос?
По железу немного переформулирую вопрос:
Просто иногда бывают сервисы, которым нужно много ходить в другие сервисы и когда мы меряем время ответа, то наверное хочется учесть и штрафы за обращение в другой сервис. Как решается этот вопрос?
По железу немного переформулирую вопрос:
- Сколько вам нужно билд агентов для того чтобы проводить стандартный флоу CI и сколько нужно докинуть сверху инстансов, чтобы начать мерить производительность, так чтобы очередь в CI конвейере не разрасталась.
- Могут ли эти самые инстансы сосуществовать в рамках одной физической машины с другими виртуалками или они полностью утилизируют ресурсы физической машины, на которой запущены?
- По железу эти инстансы отличаются от обычных билд агентов?
Мгновенно. Для нас походы в сервисы по времени это «о» малое по времени. Поэтому его учет не влияет на результат. Но если нужно чистое время, то сервис пишет логи и мы умеем из них собирать реальное время работы.
1. Я боюсь, что эти цифры частные, критический путь у всех систем разных. Опять же, ничем концептуальным хосты, на которых проверяется нагрузка, не отличаются от хостов для других тестов. У нас облако общее, мы можем одновременно запускать разное число агентов, от десятков до сотен. Тесты нагрузки не большая часть из них. Это десятки агентов. Но опять же, для каких-то программ условно достаточно просто сделать билд + запуск и запустить 15 агентов на отстрел. Тогда эти десятки агентов под нагрузку будут основным куском. А нам нужно провести много подготовительных действий. Чтобы не разрасталась очередь надо иметь минимум x3 запас.
2. Нет, не могут. И даже если не утилизируют всё, им нельзя ни с кем соседствовать, чтобы обеспечить точность измерений.
3. Не отличаются
1. Я боюсь, что эти цифры частные, критический путь у всех систем разных. Опять же, ничем концептуальным хосты, на которых проверяется нагрузка, не отличаются от хостов для других тестов. У нас облако общее, мы можем одновременно запускать разное число агентов, от десятков до сотен. Тесты нагрузки не большая часть из них. Это десятки агентов. Но опять же, для каких-то программ условно достаточно просто сделать билд + запуск и запустить 15 агентов на отстрел. Тогда эти десятки агентов под нагрузку будут основным куском. А нам нужно провести много подготовительных действий. Чтобы не разрасталась очередь надо иметь минимум x3 запас.
2. Нет, не могут. И даже если не утилизируют всё, им нельзя ни с кем соседствовать, чтобы обеспечить точность измерений.
3. Не отличаются
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Тестирование производительности веб-сервиса в рамках Continuous Integration. Опыт Яндекса