Мгновенно. Для нас походы в сервисы по времени это «о» малое по времени. Поэтому его учет не влияет на результат. Но если нужно чистое время, то сервис пишет логи и мы умеем из них собирать реальное время работы.
1. Я боюсь, что эти цифры частные, критический путь у всех систем разных. Опять же, ничем концептуальным хосты, на которых проверяется нагрузка, не отличаются от хостов для других тестов. У нас облако общее, мы можем одновременно запускать разное число агентов, от десятков до сотен. Тесты нагрузки не большая часть из них. Это десятки агентов. Но опять же, для каких-то программ условно достаточно просто сделать билд + запуск и запустить 15 агентов на отстрел. Тогда эти десятки агентов под нагрузку будут основным куском. А нам нужно провести много подготовительных действий. Чтобы не разрасталась очередь надо иметь минимум x3 запас.
2. Нет, не могут. И даже если не утилизируют всё, им нельзя ни с кем соседствовать, чтобы обеспечить точность измерений.
3. Не отличаются
1. Не совсем на каждый, через небольшой интервал. Всё таки коммитов много, а весь граф тестов не легкий. Но при этом система CI всегда находит коммит, который внес значительное изменение.
2. У нас большую часть времени в цикле занимает подготовка индексов, на которых работает сервис. Но это наша специфика. Они занимают терабайты суммарно и строятся из нескольких источников. Если говорить про тесты, которые измеряют RPS, то они занимают час каждая итерация, которые проводятся параллельно. Если про железо. Нужна возможность запустить эту часть CI на отдельной «чистой» машине, чтобы измерения были правильными. В нашей системе запуска такая возможность есть, мы указываем необходимую нам конфигурацию хоста, выбирается подходящий и тест на хосте работает один. Мы не делаем отдельное тестовое окружение, но да, на час машина занята только 1 тестом.
3. Правильно, у нас разные машины на проде и на тестах.
4. Мокаем. Поднять все сервисы, значит по сути провести интеграционное тестирование. Это не то, что мы тут хотим. Данные для мока мы готовим заранее из логов в продакшене.
5. В основном нет. Если это не предусмотрено изначально, мы такие коммиты в прод не пускаем. А ещё мы все фичи выпускаем с возможностью их быстрого выключения, так что, если в продакшене какое-то включение неожиданно дает дополнительную нагрузку, то мы быстро фичу вырубаем.
1. Я боюсь, что эти цифры частные, критический путь у всех систем разных. Опять же, ничем концептуальным хосты, на которых проверяется нагрузка, не отличаются от хостов для других тестов. У нас облако общее, мы можем одновременно запускать разное число агентов, от десятков до сотен. Тесты нагрузки не большая часть из них. Это десятки агентов. Но опять же, для каких-то программ условно достаточно просто сделать билд + запуск и запустить 15 агентов на отстрел. Тогда эти десятки агентов под нагрузку будут основным куском. А нам нужно провести много подготовительных действий. Чтобы не разрасталась очередь надо иметь минимум x3 запас.
2. Нет, не могут. И даже если не утилизируют всё, им нельзя ни с кем соседствовать, чтобы обеспечить точность измерений.
3. Не отличаются
2. У нас большую часть времени в цикле занимает подготовка индексов, на которых работает сервис. Но это наша специфика. Они занимают терабайты суммарно и строятся из нескольких источников. Если говорить про тесты, которые измеряют RPS, то они занимают час каждая итерация, которые проводятся параллельно. Если про железо. Нужна возможность запустить эту часть CI на отдельной «чистой» машине, чтобы измерения были правильными. В нашей системе запуска такая возможность есть, мы указываем необходимую нам конфигурацию хоста, выбирается подходящий и тест на хосте работает один. Мы не делаем отдельное тестовое окружение, но да, на час машина занята только 1 тестом.
3. Правильно, у нас разные машины на проде и на тестах.
4. Мокаем. Поднять все сервисы, значит по сути провести интеграционное тестирование. Это не то, что мы тут хотим. Данные для мока мы готовим заранее из логов в продакшене.
5. В основном нет. Если это не предусмотрено изначально, мы такие коммиты в прод не пускаем. А ещё мы все фичи выпускаем с возможностью их быстрого выключения, так что, если в продакшене какое-то включение неожиданно дает дополнительную нагрузку, то мы быстро фичу вырубаем.