Бенчмаркинг с помощью googletest?
Справочная информация (переходите к вопросу ниже, если не интересуетесь)
У меня есть симулятор, который работает в трех состояниях:
- Однопоточный запуск (ввод-вывод в порядке)
- Многопоточный, связанный с ЦП в памяти стадия моделирования (ввод / вывод не в порядке)
- Однопоточный этап после моделирования, после соединения (ввод / вывод в порядке)
Что за черт! Во время стандартного тестирования загрузка ЦП упала с 100% до 20% , а общий запуск занял в 30 раз больше времени, чем обычно (130 секунд против 4,2 секунды).
Когда Callgrind не обнаружил ничего подозрительного, у меня закружилась голова, когда я был на грани отката к последней фиксации, потеряв все исправления ошибок.
Обескураженный, я вошел в серверную во время пробежки и заметил неприятные скрежеты, которые, как выяснилось позже, были вызваны записью в сокеты Mysql в / proc / PID / fd !!! Оказалось, что код Mysql, находящийся на нескольких уровнях на этапе 2, вызывал проблемы.
Извлеченные уроки
- Случайный ввод-вывод может быть смертельным для приложения реального времени
- Модульного тестирования недостаточно: мне тоже нужен бенчмаркинг
Исправление Я представлю поток-локальное хранилище IOSentinels и asserts () в ReadAllowed () и WriteAllowed (), чтобы гарантировать, что потоки этапа 2 никогда не будут выполнять операции ввода-вывода.
Вопрос
Кому-нибудь повезло с прикреплением / написанием среды тестирования с помощью googletest?
К сожалению, на этот раз все мои googletests прошли. Если бы я немного отошел и вернулся, не замечая времени выполнения, это было бы катастрофической фиксацией и, возможно, гораздо труднее исправить.
Я бы хотел, чтобы googletest завершился неудачно, если запуск занимает> 2 или 3 раза больше времени последнего выполнения: эта последняя часть сложна, потому что для очень быстрых запусков состояние системы может привести к тому, что что-то займет в два раза больше времени, но все равно будет нормально. Но при длительном прогоне / тесте моделирования я не ожидаю, что время выполнения сильно изменится (> 50% было бы необычно).
Я открыт для предложений здесь, но было бы неплохо иметь проверку, не требующую особого обслуживания, которая работала бы с автоматическим тестированием, чтобы было очевидно, если система внезапно замедлится, даже если все результаты кажутся нормальными.