Тестирование производительности перед закупкой: бенчмарки и отчет

Зачем тестировать перед закупкой и что считать реальной нагрузкой

Паспортные характеристики полезны, но редко отвечают на главный вопрос: как техника поведет себя в ваших задачах. Частота процессора, объем памяти и обещания вроде «до X IOPS» не показывают, что будет при одновременных пользователях, очередях запросов, пиковых нагрузках и типичных узких местах именно вашей инфраструктуры.

«Реальная нагрузка» - это не абстрактный стресс-тест, а набор действий, которые люди и системы выполняют каждый день. Обычно это смесь офисных приложений, работы с базами данных, файловых операций, почты, виртуальных рабочих мест, 1С/ERP, аналитики, видеонаблюдения, медицинских или учебных систем. Важно описать не только «что запускается», но и сколько пользователей делает это одновременно, в какие часы, с какими файлами и какие задержки для вас приемлемы.

Без тестирования чаще всего ошибаются в трех решениях. Во-первых, переплачивают за «сильный CPU», хотя упираются в диск или сеть. Во-вторых, берут конфигурацию впритык: в среднем она выглядит хорошо, но «сыпется» в пик. В-третьих, сравнивают разных поставщиков в разных условиях: отличаются версии ПО, драйверов, настройки BIOS/UEFI, режимы энергосбережения и даже планы электропитания в ОС.

Оценивайте не только среднюю скорость, а то, что в итоге чувствуют пользователи и администраторы. Обычно лучше всего показывают картину: p95/p99 задержек (как часто случаются «тормоза»), стабильность результатов от прогона к прогону, поведение системы при росте нагрузки и в пике, запас по ресурсам (CPU/RAM/диск/сеть) в рабочие часы и скорость восстановления после всплеска.

Иногда хватает простого пилота на 1-2 устройствах: например, когда вы обновляете офисные ПК или добавляете типовые серверы в существующий кластер, а требования понятны. Но если система критичная (финансы, госуслуги, медицина, учебные платформы), планируется масштабирование или простой слишком дорог, нужен стенд с повторяемыми сценариями, фиксированными настройками и одинаковыми образами ОС.

Практичный подход такой: сначала сформулируйте 3-5 рабочих сценариев, затем добавьте 1-2 синтетических теста для диагностики, чтобы быстрее найти узкое место. Так тестирование производительности перед закупкой даст и честное сравнение поставщиков по производительности, и объяснение, почему один вариант быстрее или стабильнее другого.

Подготовка: цели, критерии и одинаковые условия сравнения

Тестирование начинается не с запуска бенчмарка, а с короткого документа, где заранее зафиксировано, что именно измеряется и в каких условиях. Без этого результаты легко превращаются в спор про настройки вместо полезного сравнения.

Сформулируйте 3-5 целей, которые отражают работу пользователей и сервисов: время отклика в приложении, пропускная способность (сколько операций в секунду), время выполнения типовой задачи, стабильность под нагрузкой и предсказуемость (насколько «плавают» результаты между прогонами). Если цель одна, чаще выигрывает не «самые большие цифры», а вариант «достаточно быстро и без провалов».

Дальше опишите профили пользователей и задачи. Для ПК это может быть офисный сотрудник (браузер, почта, документы), оператор с несколькими окнами и базой данных, инженер с тяжелыми расчетами или графикой. Для серверов - база данных, виртуализация, файловые сервисы, аналитика, терминальные сессии. Один и тот же «быстрый процессор» ведет себя по-разному в зависимости от того, упирается ли задача в CPU, диск или сеть.

Что зафиксировать, чтобы сравнение поставщиков было честным

Перед стартом закрепите одинаковые условия для всех участников и оформите это как требования к стенду и прогону. Минимум, который стоит зафиксировать:

• Конфигурация и режимы: версия ОС, планы питания, настройки BIOS/UEFI, обновления, драйверы.
• Накопители и сеть: тип диска и объем, режим RAID, скорость и порты сети, одинаковые кабели и коммутаторы.
• Фоновые факторы: что выключено (например, индексация и сканирование), какие сервисы обязаны быть включены.
• Методика: число прогонов, разогрев перед измерениями, порядок тестов, правила фиксации «провалов».
• Формат результата: какие метрики сдаем (среднее, p95/p99, минимум), в каких единицах, какие логи прикладываем.

Заранее задайте критерии приемки: «минимум» (ниже нельзя) и «желательно» (цель). Например: «время отклика не хуже X», «не более Y% просадок», «задача выполняется не дольше Z минут». Это снимает вопрос, что делать с вариантом, который «иногда быстрый, но нестабильный».

Отдельно выберите окно повторов. Хорошо, когда все поставщики тестируются в сопоставимое время и с одинаковой длительностью, а часть прогонов повторяется в разные дни. Так проще отделить реальную разницу в железе от случайных факторов.

Если у вас важны локальная поддержка и предсказуемость поставок (часто это актуально для госсектора и крупных организаций), добавьте к техническим критериям отдельный блок про сервис: условия поддержки, сроки замены, доступность запчастей и регламент реакции. Это не «производительность», но на итоговое решение влияет напрямую.

Бенчмарки для серверов: CPU, память, диск, сеть

Бенчмарки для серверов стоит подбирать так, чтобы они отвечали на один вопрос: где будет узкое место именно в ваших задачах. Для тестирования производительности перед закупкой важны не только пиковые числа, но и стабильность под длительной нагрузкой, потому что сервер работает часами, а не минутами.

CPU: однопоток, многопоток и стабильность

CPU проверяйте в двух режимах. Однопоточные результаты важны для баз данных, приложений с лицензированием по ядрам и задач с последовательными этапами. Многопоточные показывают потенциал в виртуализации, аналитике и параллельных сервисах.

Добавьте длительный прогон на 2-8 часов и смотрите, не падает ли частота из-за перегрева или лимитов питания. Если по журналам видно ошибки, а производительность «гуляет», это важнее красивого среднего значения.

Память: скорость, задержки и заполнение

По памяти смотрят пропускную способность и задержки, но не в вакууме. На практике сервер часто работает при высокой занятости ОЗУ: активный кэш, много потоков, параллельные сервисы.

Полезно прогнать тесты и на «свежей» системе, и при заполнении памяти до 70-90%. Так видно, как меняется скорость, нет ли проблем с конфигурацией каналов, частотами или набором модулей.

Диск и сеть: не только мегабайты в секунду

Для дисков обычно важны четыре вещи: последовательное чтение/запись, случайные операции (IOPS), задержки (latency) и стабильность результатов при длительном прогоне. Для сети, кроме пропускной способности, проверьте стабильность потока и нагрузку на CPU при высокой скорости.

Чтобы сравнение поставщиков было честным, зафиксируйте как минимум:

• версии прошивок BIOS/BMC и настройки питания;
• схему RAID, тип контроллера, размер блока и параметры кэширования;
• размер пакетов и число потоков в сетевых тестах;
• температуру, частоты CPU и признаки троттлинга;
• ошибки: ECC, дисковые, сетевые, неожиданные перезагрузки.

Если вы оцениваете серверы для госсектора или крупных организаций, просите поставщика повторить те же прогоны на сопоставимых условиях и приложить сырые логи. Это упрощает проверку и повышает доверие к итоговым цифрам.

Бенчмарки для ПК и рабочих станций: от офиса до тяжелых задач

Для ПК важнее не максимальный балл, а предсказуемость в ваших сценариях. Один и тот же компьютер может быть быстрым в синтетике, но «проседать» при видеозвонке с десятком вкладок или при долгом рендере из-за нагрева.

Для офисных сценариев берите проверки, которые отражают отзывчивость при многозадачности: запуск приложений, переключение окон, работа в браузере с тяжелыми страницами, документы и видеосвязь. Удобно прогонять один и тот же набор действий (скриптом или по чек-листу) и фиксировать время выполнения и число «подвисаний».

Для графики разделяйте 2D и базовое 3D. В 2D смотрите большие проекты со слоями, масштабирование, применение фильтров. В 3D важны не только пиковые FPS, но и стабильность при вращении модели, работе с текстурами и тенями. Если сравниваете рабочие станции с разными GPU, выравнивайте версии драйверов и настройки качества.

Инженерные и аналитические задачи часто упираются сразу в CPU, память и дисковую подсистему. Хороший признак - когда большие таблицы пересчитываются без длинных пауз, а моделирование или расчеты не «забивают» систему так, что параллельно невозможно открыть документацию и почту.

Чтобы не распыляться, соберите небольшую «корзину» тестов под роли. Например: офисный профиль (браузер, документы, видеозвонок, копирование файлов), графический профиль (2D-проект плюс простая 3D-сцена) и инженерный/аналитический профиль (расчет или моделирование плюс большая таблица). Отдельно добавьте проверку диска через «время до результата» (открытие и сохранение типового проекта) и длительный прогон на 30-60 минут, чтобы увидеть падение частот.

Хранение данных оценивайте не абстрактными цифрами, а конкретным временем: сколько секунд открывается типовой проект и сколько сохраняется после правок. Если у отдела большие библиотеки или кэш, отдельно измерьте работу с папками, где десятки тысяч файлов.

Шум, нагрев и троттлинг - это тоже часть производительности. Поставщик может показать отличные цифры в коротком тесте, но через 15 минут частоты упадут, а вентиляторы будут мешать в кабинете. Поэтому фиксируйте температуры и частоты в начале и в конце прогона, стабильность (вылеты, фризы, артефакты) и одинаковые условия питания и энергосбережения.

Простой ориентир: для бухгалтерии и контакт-центра решающими будут скорость переключения между браузером, CRM и видеосвязью, а для проектного отдела - стабильность под длительной нагрузкой и быстрые сохранения больших файлов. Именно под такие различия и стоит подбирать сценарии нагрузки для ПК, а не искать один универсальный балл.

Сценарии ближе к работе: синтетика плюс прикладные задачи

Синтетические тесты полезны, когда нужно быстро понять пределы железа и сравнить несколько конфигураций по одной шкале. Они хорошо показывают разницу в CPU, памяти или диске, но легко вводят в заблуждение, если делать выводы о реальной работе пользователей. В жизни нагрузка редко бывает ровной и однотипной.

Чтобы тест был ближе к правде, добавьте прикладные проверки: измеряйте время типовой операции, которую ваша организация делает каждый день. Такой результат понятнее руководителю и проще защищается на закупочной комиссии: не «на 15% быстрее», а «отчет формируется за 2 минуты вместо 3».

Обычно больше всего пользы дают несколько простых прикладных тестов: для сервера - восстановление базы из бэкапа и выполнение набора типовых запросов, развертывание виртуальной машины или контейнера и запуск стандартного сервиса; для ПК - открытие большого файла и экспорт в PDF; для рабочей станции - рендер короткой сцены или пакетная обработка 50-100 фото; для всех - копирование большого набора файлов и измерение времени индексации или поиска.

Дальше важный шаг - смешанные нагрузки. В реальности CPU, диск и сеть загружены одновременно: сервер принимает запросы, пишет логи на диск и параллельно отдает данные по сети. Если тестировать по очереди, можно не заметить узкое место. В смешанном сценарии часто выигрывает не самая «быстрая» по синтетике система, а та, что держит темп без провалов.

Смотрите не только на скорость, но и на отклик. Пользователю важна ровная работа без редких, но длинных зависаний. Поэтому фиксируйте не только среднее время, но и разброс (минимум/максимум или стандартное отклонение) и p95/p99, а также поведение под нагрузкой: появляются ли паузы, растет ли очередь операций, падает ли скорость через 10-15 минут.

Короткие тесты хороши для первичного сравнения и поиска явных проблем. Длительные прогоны показывают троттлинг, нагрев, влияние фоновых задач и стабильность дисковой подсистемы. Часто удобно сочетать 10-15 минут быстрых прогонов и 2-4 часа длинных.

Если вы проводите тестирование производительности перед закупкой у разных поставщиков, просите повторять один и тот же набор сценариев на одинаковых настройках. При оценке серверов и ПК у локального производителя это особенно полезно: вы проверяете не «пиковые» цифры, а длительную стабильность в вашей типичной нагрузке.

Пошаговый план тестирования: от стенда до повторяемых прогонов

Главное в тестах - повторяемость. Тестирование производительности перед закупкой должно отвечать на простой вопрос: кто дает лучший результат в одинаковых условиях и насколько эти результаты стабильны.

Соберите небольшой стенд, который можно быстро пересобрать и проверить. Зафиксируйте все, что влияет на цифры: модель и версию BIOS/UEFI, режим питания, настройки Turbo и энергосбережения, драйверы, версии ОС и гипервизора (если он есть), а также температуру в помещении. Если тестируете нескольких поставщиков, заранее договоритесь: изменения конфигурации недопустимы без записи в протокол.

Рабочая последовательность, которая обычно дает чистые сравнимые результаты:

• Сделайте эталон: один и тот же образ ОС, одинаковые настройки, профили питания и учетные записи, плюс список версий ПО и драйверов.
• Подготовьте тестовые данные заранее и храните их как «золотой набор» (например, одинаковая база, архив файлов, набор виртуальных машин).
• Перед измерениями прогрейте систему и проверьте фон: обновления, антивирусные сканы, индексацию, телеметрию, резервное копирование.
• Каждый сценарий запускайте несколько раз и фиксируйте разброс, а не только лучший прогон. На практике обычно хватает 3 прогонов и расчетов среднего и отклонения.
• Добавьте длинный прогон (час и больше, если позволяет окно) и проверьте стабильность: троттлинг, падение частот, ошибки диска, деградацию сети.

Сами прогоны удобно организовывать пакетно: один сценарий - один способ запуска - один набор логов. Так проще повторить тест через неделю, когда появится другой участник или обновится прошивка.

Чтобы сравнение не превратилось в спор, заранее решите, что именно записываете в отчет. Минимальный набор обычно такой: полная конфигурация железа и ПО (включая версии прошивок), результат каждого прогона и сводные значения, метрики стабильности (температуры, частоты, ошибки, перезапуски) и сырые логи с временем выполнения.

Пример из практики: вы выбираете два одинаковых по цене rack-сервера под виртуализацию. Короткие тесты показывают близкие цифры, но длинный прогон выявляет, что один сервер через 30-40 минут снижает частоты из-за охлаждения. Это видно сразу: среднее падает, разброс растет.

В конце сложите все артефакты в отдельную папку на каждого участника: конфиг, логи, скриншоты и таблицу. Если оборудование поставляет местный производитель и интегратор, например GSE.kz, попросите приложить заводские протоколы и серийные номера к вашему набору, чтобы потом не было вопросов, что именно тестировали.

Как оформить результаты, чтобы честно сравнить поставщиков

Сильный отчет по тестам нужен не для красоты, а чтобы любое сравнение можно было повторить. В теме «сравнение поставщиков по производительности» спор почти всегда начинается не о цифрах, а о том, в каких условиях их получили.

Начните с единого шаблона описания стенда. Зафиксируйте точные модели CPU и накопителей, объем и частоту памяти, версии BIOS и прошивок, драйверы, ОС и ее обновления, а также режимы питания. Отдельно укажите настройки RAID, профили вентиляторов, лимиты мощности и включенные функции безопасности, если они меняют производительность.

Дальше оформляйте результаты по сценариям, а не в стиле «одно лучше другого». Удобно разбить на 3-5 рабочих сценариев (например: база данных, виртуализация, файловый сервер, офисная нагрузка на ПК) и для каждого показать набор метрик. Одного среднего значения мало: оно прячет провалы.

Минимальный набор полей, который делает таблицу честной:

• Среднее и медиана.
• p95 (а для чувствительных сценариев - p99).
• Разброс (min-max или стандартное отклонение) и число прогонов.
• Единицы измерения и методика (что считали: IOPS, мс задержки, запросы/сек).
• Порог приемки (что считается «проходит/не проходит» именно для вашего кейса).

Рядом с цифрами держите «журнал ограничений». Если был троттлинг CPU, перегрев, ошибки SMART, сетевые ретраи, падение частоты памяти или неожиданная фоновая активность, это должно быть отмечено отдельной строкой с временем и симптомом. Такие детали часто объясняют, почему два одинаковых на бумаге сервера ведут себя по-разному.

В финале сделайте короткий вывод на 5-7 строк: какие сценарии прошли пороги, где есть риски и почему. Например: «Поставщик A подходит для виртуализации (стабильный p95), но не проходит по задержке диска в пик; у поставщика B выше среднее, но сильный разброс из-за троттлинга». Такой формат проще защищать на закупочной комиссии.

Пример из практики: как выбрать серверы для типовой организации

Организация на 150 сотрудников планирует обновление инфраструктуры. Нужны файловый сервис для общих папок, сервер под 1С и базу данных, а также резервное копирование. Поставщика два, характеристики на бумаге похожи, но важно понять, как это будет работать вживую. Здесь и помогает тестирование производительности перед закупкой.

Сначала описывают три сценария, которые повторяются каждую неделю и дают реальную нагрузку. Утром, когда все приходят, запускаются 1С, открываются документы, идет активная работа с файлами. В отчетный период растет число тяжелых запросов в базе и печатных форм. Ночью выполняются бэкапы и, если есть, проверка целостности, что часто упирается в диск и сеть.

Чтобы сравнение было честным, на стенде выставляют одинаковые условия: одна и та же версия ОС и СУБД, одинаковые настройки 1С, одинаковый объем тестовых данных, одинаковая схема сети. Если поставщик предлагает разные классы дисков или RAID, это фиксируют отдельными вариантами, а не смешивают в одном тесте.

Измерять стоит не только «сколько баллов в бенчмарке», а показатели, которые ощущаются в работе: время отклика ключевых операций (вход в 1С, проведение документа, построение отчета), задержки диска и глубина очереди, загрузка CPU и память (включая своп), сеть (скорость и потери), ошибки приложений и таймауты в журналах.

Дальше результаты переводят в понятные формулировки. Например: «утренний пик: 150 одновременных сессий 1С, среднее время проведения документа 1,2 секунды, p95 - 2,0 секунды». Для бэкапов: «полная копия 2 ТБ завершилась за 3 часа, окно укладывается в ночь». Так появляется практичная метрика «цена за выполненный сценарий»: стоимость комплекта соотносят с тем, что он реально обеспечивает при заданных задержках.

Решение принимают по правилу: минимальные требования закрыты, есть запас на рост (часто 20-30% по ключевым узким местам) и понятны условия поддержки. В Казахстане нередко критичны сроки поставки и сервис по стране, поэтому сервисный блок стоит оценивать отдельно, наравне с цифрами.

Частые ошибки и ловушки, которые портят результаты

Даже хорошие бенчмарки бесполезны, если условия сравнения «плывут». В тестировании производительности перед закупкой чаще ошибаются не в выборе теста, а в дисциплине: что именно измеряли, на каком железе и с какими настройками.

Самый неприятный сценарий - когда под видом одинаковых предложений сравнивают разные конфигурации. Один поставщик ставит более быстрый SSD или больше каналов памяти, другой - базовую комплектацию, а в таблице это выглядит как честное сравнение. Перед стартом фиксируйте точные модели CPU, объем и частоту RAM, тип накопителей (SATA/NVMe), сетевые карты, а для ПК - видеокарту и лимиты по питанию.

Не менее часто забывают про BIOS/UEFI и энергосбережение. У серверов и рабочих станций один переключатель (профиль питания, Turbo, C-states, лимиты мощности) способен дать заметную разницу. Если настройки не записаны, вы не сможете объяснить, почему «вчера было быстрее».

Типовые ловушки, из-за которых результаты становятся непригодными для выбора:

• Один прогон вместо серии: без 3-5 повторов не видно разброс и случайные провалы.
• Смешивание разных версий ОС, драйверов и микрокода: обновления меняют скорость и стабильность.
• Оценка только средней скорости: среднее может быть «красивым», а задержки и просадки будут мешать работе.
• Фоновая нагрузка: антивирус, обновления, телеметрия, бэкапы во время теста.
• Разные условия стенда: один тестируют на «холодном» железе, другой - в тесном шкафу без нормальной вентиляции.

Отдельный класс ошибок связан с тем, что игнорируют реальную эксплуатацию. Температура, питание и шум важны: при перегреве система уходит в троттлинг, при нестабильном питании падает частота, а слишком громкая система может быть неприемлема для кабинета или лаборатории.

Практичный пример: два сервера показывают одинаковый результат по CPU в синтетике. Но у одного под нагрузкой растет задержка диска и появляются короткие провалы производительности из-за перегрева или агрессивного энергосбережения. Если в отчете есть только среднее значение, проблему легко пропустить до пилота.

Чтобы защититься от сюрпризов, добавьте в протокол три вещи: фиксированный «паспорт» конфигурации, журнал версий ПО и режимов питания, и показатели стабильности (минимум, p95, температура и частоты под нагрузкой). Тогда сравнение будет честным и повторяемым.

Быстрый чек-лист перед выбором и следующие шаги

Перед подписанием договора убедитесь, что вы сравниваете не красивые цифры, а то, что будет влиять на работу пользователей и сервисов каждый день. Тестирование производительности перед закупкой должно отражать ваши типовые задачи и редкие пики, иначе победит не лучший вариант, а самый удачно настроенный под синтетику.

Пять контрольных пунктов:

• Сценарии нагрузки совпадают с реальной жизнью: типовые операции, пиковые часы, рост данных, резервное копирование, обновления.
• Условия у всех поставщиков одинаковые: версии ОС и драйверов, настройки BIOS, режимы питания, одинаковые лимиты по охлаждению и шуму, сопоставимые профили безопасности.
• По каждому сценарию есть метрики и пороги приемки: время отклика, пропускная способность, p95/p99 задержек, стабильность под длительной нагрузкой, число ошибок.
• Есть подтверждение воспроизводимости: минимум 3 прогона, понятная методика усреднения, фиксация отклонений и причин.
• На руках исходные артефакты: логи тестов, конфигурация стенда и параметры запуска, чтобы результаты можно было повторить.

Если хотя бы один пункт «плавает», лучше остановиться и довести методику до ясного состояния. Это дешевле, чем спорить после поставки, почему «на демо было быстрее».

Следующие шаги, которые обычно дают самый честный ответ:

1. Согласуйте короткий пилот на 1-2 недели в боевых условиях. Выберите 1-2 типовых подразделения или сервисы и заранее закрепите, что именно измеряете каждый день.

2. Определите «красные флажки»: перегрев и троттлинг, нестабильность драйверов, скачки задержек, неожиданный расход памяти, шум или просадки под смешанной нагрузкой.

3. Оформите итог как таблицу «сценарий - метрика - порог - результат - комментарий» и добавьте раздел «условия теста», чтобы сравнение поставщиков по производительности было защищено от споров.

Если вы планируете пилот и хотите заранее подобрать конфигурации под ваши сценарии, обсуждать методику и состав стенда удобнее с поставщиком, который готов работать по повторяемым тестам и вести поддержку. Например, GSE.kz как производитель и системный интегратор в Казахстане может предоставить серверные платформы S200 и рабочие места L200, а вы сможете прогнать их в тех же условиях, что и альтернативы, и сравнить результаты по вашим порогам приемки.