Руководство по проведению осмысленного тестирования производительности компьютера

Программы для тестирования производительности пытаются анализировать «эффективность» компьютера на основе строго определенных тестовых условий (которые обычно даже близко не соответствуют финальной конфигурации компьютера). Разработчик теста может использовать различные способы, чтобы обойти ограничения — например, при работе с системными ресурсами, виртуальной программной средой, приложениями, симуляцией вычислительной нагрузки, пользовательской нагрузки или общей нагрузки на систему — и сделать все необходимое для преодоления этих ограничений, чтобы получить выгодный результат. «Наличие отраслевого стандарта тестирования — это всегда хорошо, если результаты тестов не подтасовываются. К сожалению, многие отраслевые тесты именно так и работают. […] Тем не менее, многие организации, похоже, покупают оборудование, основываясь на результатах тестов, вместо того чтобы понять свои рабочие нагрузки и приобретать технику, исходя из реальных требований и, конечно, бюджета» (Newman, 2015). Это объясняет, почему покупателю необходимо точно знать, что именно измеряется. Программа для тестирования никогда не сможет отразить так называемый «реальный опыт использования»; она лишь покажет, насколько хорошо эта программа работает на конкретном компьютере. Поэтому обязанность покупателя — определить, как эти результаты будут применены в его рабочей среде.

Как ни странно, правильно провести тестирование очень сложно, поскольку существует множество возможностей получить неверные или вводящие в заблуждение результаты, а также упустить из виду важные аспекты. В «Белой книге» (white paper) «Девятилетнее исследование тестирования файловых систем и хранилищ данных» это резюмируется следующим образом:

В этой статье мы рассмотрели 415 тестов файловых систем и хранилищ из 106 недавних научных работ. Мы обнаружили, что большинство популярных тестов имеют недостатки, а многие исследовательские работы не дают четкого представления об истинной производительности (Traeger, Zadok, Joukov, & Wright, 2008).

В этой же «Белой книге» говорится, что тесты должны объяснять, что именно тестируется и почему, а также содержать (или упрощать) своего рода анализ ожидаемой производительности системы.

В статье «Performance Anti-Patterns» (Антипаттерны производительности) выделены ключевые моменты, определяющие, для чего и как следует проводить тесты. Таким образом, хороший тест должен быть:

• Повторяемым, чтобы можно было относительно легко проводить сравнительные эксперименты с разумной степенью точности.
• Наблюдаемым, чтобы при обнаружении низкой производительности разработчик понимал, с чего начать поиск проблемы. Нет ничего более неприятного, чем сложный тест, выдающий одну цифру, не давая разработчику никакой дополнительной информации о том, где кроется проблема.
• Переносимым, чтобы можно было проводить сравнения с основными конкурентами (даже если это ваши предыдущие релизы). Сохранение истории производительности предыдущих версий — ценный инструмент для понимания вашего собственного процесса разработки.
• Легким для представления, чтобы каждый мог понять результаты сравнения в ходе краткой презентации.
• Реалистичным, чтобы измерения отражали реальный опыт пользователя.
• Быстрым в запуске, чтобы все разработчики могли оперативно оценить последствия своих изменений. Если получение результатов производительности занимает дни, это будет происходить нечасто.

Не все выбранные тесты будут соответствовать всем этим критериям, но важно, чтобы хотя бы часть из них им отвечала. Смолдерс (Smaalders) призывает выбирать тесты, которые действительно отражают потребности клиента, иначе все усилия будут направлены на оптимизацию не того поведения. Он также советует сопротивляться искушению оптимизировать систему под тест ради победы любой ценой. Такое поведение приведет к фальшивым результатам, что вызовет недоверие к бренду или поставщику. Как правило, тест подсветит именно тот аспект, под который он был оптимизирован, в ущерб другим параметрам, которые не измерялись (и которые могут быть важны для клиента) (Smaalders, 2006).

Есть еще один момент при сравнении различных систем с целью покупки: соотношение цены и производительности. Этот показатель можно рассчитать, включая пятилетнюю стоимость владения оборудованием (Anon & Gray, 1985).

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

• Тест никогда не отразит реальное использование. Будучи полностью автоматизированной программой, она будет открывать, записывать, настраивать, читать, сохранять, отображать, просматривать, перемещать, вычислять, назначать и выполнять многие другие задачи полностью автоматически. Этот темп никогда не отразит скорость, с которой человек выполняет свою работу. Поэтому любая программа, обещающая результаты, основанные на «реальном использовании», лжет.
• Не все тесты оценивают многозадачность. Подавляющее большинство тестов оценивают только последовательно выполняемые задачи. Они тестируют одно, затем другое. Они почти никогда не заставляют приложение делать что-то, пока другое приложение занято чем-то иным (а если и делают, то обычно ограничиваются двумя, максимум тремя экземплярами). В реальной жизни пользователи запускают несколько приложений одновременно. Большинство пользователей открывают множество программ сразу (операционная система также выполняет много задач, пока мы заняты своими делами). Стоит отметить, что результат теста, отражающего всего один процесс или приложение, не масштабируется линейно при добавлении второго, третьего и последующих процессов. Поэтому к результатам современных тестов на многоядерных технологиях стоит относиться скептически.
• «Показатель» — это не то же самое, что «производительность». Показатель — это просто число, выданное программой. Производительность — это нечто гораздо более сложное. Число зависит от программы тестирования и шкалы, заданной ее разработчиками. Производительность — это выполнение заданной задачи, измеренное в соответствии с заданными стандартами точности, полноты, стоимости и скорости (The Business Dictionary, 2017). Поэтому ни один показатель теста не отражает реальный индекс производительности.
• Тесты неточны. Отклонение показателей в тестах может достигать 10% (иногда и больше). Эти показатели всегда субъективны, что противоречит объективным принципам науки и техники. Именно поэтому программу тестирования следует запускать как минимум 3 раза, чтобы рассчитать среднее значение. После определения среднего ожидается разброс не более +/-3% (этот показатель можно вычислить на основе собранных результатов).
• Результаты тестов могут быть манипулированы. Существуют способы манипулирования результатами программ тестирования для получения искусственно завышенных показателей, чтобы впечатлить пользователя. Этого можно добиться с помощью множества техник: чрезмерной оптимизации настроек BIOS, модификации аппаратного обеспечения, использования специальных драйверов, манипуляций с кодом и прочего. Показатели могут быть получены в нереалистичных условиях, не соответствующих реальной практике: систему требуют очистить от всех программ и процессов, выставить специфические параметры, которые зависят от конкретного теста, что не отражает то, как компьютер будет использоваться для работы. Как сказал Генри Ньюман: «Что нам говорит тест: 1) Сколько оборудования поставщик смог запихнуть в коробку, 2) Насколько хорошо команда поставщика может оптимизировать программное обеспечение [под тест], и 3) Насколько сильно поставщик хочет закрыть сделку» (Olds & OrionX, 2011). Если покупатель заранее не установил четкий протокол тестирования, открывается дверь для любых трюков, с помощью которых тестировщик может достичь (или превзойти) желаемых результатов, чтобы впечатлить клиента.

В конечном счете, программа тестирования не является точным инструментом, и использовать ее следует с осторожностью. Как процитировал Генри Ньюман в личном общении: «Сравнивать инструменты производительности систем [...] с [...] тестами — это как сравнивать яблоки с летающими свиньями» (Carrier, 2012).

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

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

• Будет использоваться с текущими графическими операционными средами (Windows 10 или дистрибутивы GNU/Linux как минимум)
  • Или если он будет использоваться с предыдущими версиями операционных систем, такими как Windows 7 или Windows 8.1, либо предыдущими дистрибутивами GNU/Linux.
• Базовая продуктивность (запущено не более 5 приложений, включая):
  • Антивирус
  • Текстовый процессор
  • Электронная почта
  • Легкое использование электронных таблиц
  • Веб-приложения
  • Веб-браузер с открытыми не более чем 6 вкладками.
• Стандартная продуктивность (запущено от 5 до 10 приложений, включая):
  • То же, что и для базовой продуктивности, плюс…
  • Офисные приложения (текстовый процессор с обработкой изображений, таблицы с формулами и некоторыми скриптами, презентации, базовое управление базами данных)
  • Веб-браузер с открытыми до 15 вкладок
  • Веб-конференции
  • Просмотр и простое редактирование изображений и видео
  • Образование
  • Можно предположить активное использование видео, изображений, анимации, веб-доступа и приложений, использующих ускоренные вычисления.
• Продвинутый пользователь (запущено более 10 приложений, включая):
  • То же, что и для стандартной продуктивности, плюс…
  • Разработка приложений
    • Использование языков программирования и сред разработки
    • Создание, управление и тестирование баз данных
    • Тестовая среда с виртуализацией
    • Контролируемые среды тестирования
  • Программы для научных исследований
    • Специализированные приложения
    • Инженерные и научные приложения
    • Виртуальная реальность
• Для справки: игры в настоящее время рассматриваются как высокопроизводительные вычисления (Stevenson, Le Du, & El Afrit, 2011)
• Другие критерии
  • Требуется ли низкое энергопотребление?
  • Важен ли или ограничен ли занимаемый компьютером объем пространства?
  • Требуется ли мобильность?
  • Важно ли время автономной работы?
  • Важен ли вес?
  • Другие виды использования, подразумевающие эксплуатацию в суровых, пыльных или шумных условиях.

Термин в заголовке этого раздела может показаться странным, но на самом деле это проблема, которую обычно игнорируют. Он относится к следующему вопросу: какое время отклика действительно важно для пользователя? Скорость и производительность — понятия относительные. Илья Григорик предлагает интересный взгляд на то, что означает слово «производительность»:

«Производительность — это не только миллисекунды, кадры и мегабайты. Это также то, как эти миллисекунды, кадры и мегабайты транслируются в то, как пользователь воспринимает приложение» (Grigorik, 2014).

Каждое приложение диктует свой набор требований в зависимости от бизнес-критериев, контекста, ожиданий пользователя и временных констант перцептивной обработки, полностью ориентированных на человека. Опять же, ожидания пользователя соотносятся с первым законом Майстера: «Удовлетворение равно восприятию минус ожидание» (Maister, 1985). Как бы быстро ни ускорялась жизнь, или, по крайней мере, как бы мы ни воспринимали это ускорение (1 кадр каждые 66 мс), наше время реакции остается постоянным. Если учесть, что, согласно традиционным исследованиям, пользователь способен воспринимать около 15 кадров в секунду (Thorpe, Fize, & Marlot, 1996), следующая таблица (основанная на военном стандарте 1472G) дает ясное представление о времени отклика, которое пользователь обычно ожидает. Это верно независимо от типа приложения (установлено на компьютере или в сети) или устройства (ноутбук, настольный компьютер или мобильное устройство).

Фактическое время и восприятие пользователем (Seow, 2008)

• 0 – 100 мс: Мгновенно
• 100 – 500 мс: Немедленно
• 500 – 1000 мс: Быстро
• 1 – 10 с: Воспринимается как задержка, но пользователь не теряет концентрацию.
• +10 с: Компьютер слишком медленный, чтобы удерживать внимание пользователя.

Чтобы ответ на запрос пользователя воспринимался как быстрый, он должен приходить менее чем за одну секунду. Если это занимает одну секунду или больше, пользователь может заметить некоторую задержку, но его внимание не будет отвлечено от задачи. После 10 секунд — если программа не предоставляет пользователю какую-либо информацию о процессе — задача обычно забрасывается, и пользователь испытывает раздражение. Если оцениваемый компьютер способен выдавать ответы за сравнимое время или менее чем за 10 секунд, пользователь получит от него больше отдачи. Эти пороги гораздо полезнее в реальном мире, чем результаты тестов, которые не предлагают четких рекомендаций относительно того, что они означают.

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

• Порог или ориентир минимально ожидаемого результата
• Что именно тестируется
• Какие факторы являются ограничивающими
• Любые помехи, которые могут повлиять на результаты
• Детали протестированной системы
• Цена (по крайней мере, средняя) протестированной системы
• Какие выводы планируется сделать на основе результатов

Порог можно получить на публичных сайтах (таких как Futuremark) или создать локально на компьютере, который уже используется и имеет хорошую конфигурацию, чтобы задать базовую линию для тестов компьютеров, которые собираются предложить. Запишите подробности конфигурации этого эталонного компьютера (процессор, память [объем, скорость, конфигурация, тайминги], хранилище, видеокарта и монитор), чтобы иметь о нем четкое представление.

Анализ результатов тестов требует времени и опыта для правильного выполнения. Как уже было сказано, самая важная часть — определить, что именно измеряется и являются ли полученные результаты значимыми для предполагаемого использования компьютеров.

Ниже предлагается протокол тестирования для обеспечения — насколько это возможно — честных и реалистичных результатов применяемых тестов.

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

Независимо от бренда или предлагаемого оборудования, все компьютеры должны соответствовать критериям конфигурации:

• Если вы запрашивали физические четырехъядерные процессоры, все они должны иметь четыре физических ядра.
• Если вы запрашивали определенный объем, скорость и конфигурацию оперативной памяти (RAM), убедитесь, что все компьютеры имеют одинаковую конфигурацию. Запишите любые различия:
  • Объем
  • Скорость (МТ/с)
  • Тайминги и задержки (CAS, RAS, tRAS, tRC, частота).
  • Одноканальный vs Двухканальный режим
• Если вы запрашивали определенный тип хранилища, убедитесь, что все компьютеры оснащены таким типом. Запишите все обнаруженные различия (пропускная способность, время поиска и записи):
  • Стандартный вращающийся жесткий диск (5400 об/мин, 7200 об/мин, 10000 об/мин, SSHD)
  • SSD
• Видеокарта должна соответствовать Shader Model 6.1 (DirectX 12.1) для Windows 10 или Shader Model 5 (DirectX 11) для предыдущих версий Windows.
• Монитор должен иметь одинаковые характеристики на каждом компьютере:
  • Частота обновления
  • Время отклика (мс)
  • Разрешение (более высокие разрешения могут привести к более низким показателям теста)
  • Глубина цвета
• Операционная система должна быть одной и той же версии и сборки.
  • В Windows можно узнать версию и сборку, набрав «winver» и нажав «Ввод» в поле поиска Cortana или после нажатия Windows+R, чтобы открыть окно «Выполнить».
• На каждом компьютере должны быть установлены только текущие драйверы, одобренные производителем компьютера. Примечание: не допускайте использования специальных или модифицированных драйверов, предоставленных производителем отдельных компонентов, так как они могут привести к фальшивым результатам. Избегайте использования драйверов, отличных от тех, что проверены и публично доступны на веб-сайте или в установочном инструменте производителя компьютера.
• Настройте компьютер в режиме «Сбалансированный». Это режим, в котором компьютеры будут использоваться заказчиком, и это самый верный способ получить результаты тестов.
• Установите приложения, обычно используемые заказчиком. Даже если они не будут использоваться непосредственно в тесте, это способ, которым компьютеры будут эксплуатироваться.
• Установите любое другое программное обеспечение (например, антивирусы и инструменты), требуемое заказчиком. Это сделает конфигурацию максимально приближенной к той, что будет у конечного пользователя.
• Установите программы для тестирования.

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

Поскольку показатели тестов могут давать разброс от 5 до 15%, рекомендуется запускать каждый тест не менее 3 раз. Каждый раз потребуется перезагрузка компьютера, ожидание около 5 минут после появления рабочего стола и только после этого — повторный запуск теста. После каждого прогона рекомендуется делать скриншот результата для сохранения доказательств. Это следует проделывать для каждой выбранной программы тестирования.

Покупатель сам решает, усреднять ли различные показатели, полученные в каждом прогоне, или брать самое высокое или низкое значение. Какое бы решение ни принял покупатель, рекомендуется применять его ко всем используемым тестам. В качестве совета — лучше использовать среднее значение.

После получения результатов их можно нормализовать (как описано в основной части документа) и затем линейно перевести во временные показатели. Учитывая стоимость компьютеров, покупатель также может оценить, какая из систем обеспечивает наилучшее соотношение цены и производительности.

Процесс тестирования требует времени, опыта и терпения. Если все сделано правильно, программы тестирования могут дать хорошее представление об ожидаемой производительности компьютера. Все записи, сделанные свидетелем, будут полезны для определения того, что именно потребуется от участника тендера в случае его выбора. Конфигурация (процессор, ОЗУ [объем, скорость, тайминги, режим работы каналов], хранилище [тип, пропускная способность, емкость], монитор, форм-фактор и т. д.), зафиксированная во время процесса, будет полезна для проверки того, чтобы доставленный компьютер был сконфигурирован в точности так же, как тестируемый. Это важно, поскольку некоторые недобросовестные поставщики могут предоставить специально настроенный компьютер только для тестирования, а в итоге — совсем другой. Поэтому это поможет покупателю получить именно то, что тестировалось.

Исходя из всего вышесказанного, можно сделать следующие выводы:

• Покупки, которые делает заказчик, предназначены для компьютеров, а не просто для процессора или конкретного компонента. Поэтому необходимо учитывать систему целиком (холистически) при принятии решения о покупке.
• Производительность компьютера зависит от всех его элементов. Это включает в себя аппаратное и программное обеспечение. Общая производительность компьютера всегда будет равна производительности его самого медленного элемента.
• Необходимо учитывать меры по энергосбережению, тепловыделение, стабильность компьютера, его сертификацию для бизнес-использования и предлагаемые службы безопасности. Современные технологии требуют не просто скорости, основанной на тестах, но и низкого энергопотребления и наличия служб безопасности.
• Важно осознавать, что новые технологии, интегрированные в приложения и операционные системы, задействуют гораздо больше, чем просто процессор. Скорее, они фокусируются на других компонентах, таких как CPU, GPGPU, шины, скорость оперативной памяти и скорость передачи данных с диска.

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

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

Anon, E. A., & Gray, J. (Февраль, 1985). A Measure of Transaction Processing Power. Проверено 22 марта 2015 г. с Internet Archive: https://archive.org/details/bitsavers_ta...

Carrier, J. (24 апреля, 2012). HPCS I/O Scenarios. Проверено с OpenSFS: http://cdn.opensfs.org/wp-content/upload...

Computerhope. (15 марта, 2015). Thrashing. Проверено с Computer hope: http://www.computerhope.com/jargon/t/thr...

Gregg, B. (2014). Systems Performance Enterprise and the Cloud (1-е изд.). США: Pearson Education.

Grigorik, I. (12 марта, 2014). Speed, Performance, and Human Perception. (Fluent, ред.) Сан-Франциско, Калифорния, США. Проверено 22 марта 2015 г. с https://www.youtube.com/watch?v=7ubJzEi3...

Hoff. (30 декабря, 2006). Multicore, SMP and SMT Processors. Проверено 22 марта 2015 г. с HoffmanLabs: http://labs.hoffmanlabs.com/node/13

Maister, D. (1985). The Psychology of Waiting Lines. (T. S. Encounter, ред.) Проверено 22 марта 2015 г. с David Maister: Professional Business, Professional Life: http://davidmaister.com/wp-content/theme...

Mallik, A. (2007). Hollistic Computer Architectures based on Application, User, and Process Characteristics. Эванстон, Иллинойс, США: UMI.

Newman, H. (2015). Data Storage Issues: Big Data Benchmarking. Проверено с InfoStor: http://www.infostor.com/index/blogs_new/...

Olds, D., & OrionX. (19 декабря, 2011). Benchmarks are $%#&@!! Проверено с The Register: http://www.theregister.co.uk/2011/12/19/...

Osterhage, W. (2013). Computer Performance Optimization (1-е изд.). (Springer-Verlag, пер.) Нидербахем, Германия: Springer-Verlag Berlin Heidelberg.

Seow, S. (2008). Designing and Engineering Time. Бостон, США: Prentice Hall.

Smaalders, B. (23 февраля, 2006). Performance Anti-Patterns. doi:1542-7790/06/0200

Stevenson, A., Le Du, Y., & El Afrit, M. (Март, 2011). High Performance Computing on Gamer PCs. Проверено с ArsTechnica: http://arstechnica.com/science/2011/03/h...

The Business Dictionary. (2017). Performance. Проверено с The Business Dictionary: http://www.businessdictionary.com/defini...

Thorpe, S., Fize, D., & Marlot, C. (6 июня, 1996). Speed of processing in the human visual system. Nature, 381, 520-522. Проверено с Quora: http://cns.bu.edu/Profiles/Mingolla.html...

Traeger, A., Zadok, E., Joukov, N., & Wright, C. (Май, 2008). A Nine Year Study of File System and Storage Benchmarking. Проверено 22 марта 2015 г. с File systems and Storage Lab (FSL): http://www.fsl.cs.sunysb.edu/docs/fsbenc...

Vieira, L. (3 октября, 2011). The Perception of Performance. Проверено 22 марта 2015 г. с Sitepoint: http://www.sitepoint.com/the-perception-...