Тест Гилёва для 1С. Почему бенчмарк не эффективен в облаке

Среди специалистов по 1С и системных администраторов есть один популярный способ измерить скорость сервера. Нагрузочный тест Гилёва — это однопоточный бенчмарк для платформы 1С: Предприятие, который измеряет скорость выполнения типовых операций на пустой базе и выдает результат в условных баллах. Запуск занимает пару минут, а на выходе получается конкретное число — 30, 50 или 100 баллов.

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

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

Что проверяет тест Гилёва

Тест Гилёва появился как инструмент для быстрой диагностики серверов, на которых работает 1С. Автор создавал его для конкретных задач, и понимание этих задач помогает не требовать от теста того, что он не умеет делать.

Оценка «голого» железа

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

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

Сравнение эталонов

Вторая задача теста — дать сравнительную метрику для разных серверов. Когда встает выбор между двумя моделями процессоров Intel Xeon, или нужно сравнить старый сервер с новым, достаточно запустить на обоих одну и ту же версию теста Гилёва в одинаковых условиях — пустая база, выключенные антивирусы, максимальная схема питания.

На выходе тест выдает показатели. Один сервер показывает 45 баллов, другой — 52. Становится понятно, что второй сервер будет быстрее в однопоточных операциях 1С примерно на 15 процентов. Без такого бенчмарка сравнить производительность процессоров для 1С практически невозможно, так как стандартные тесты плохо коррелируют с поведением 1С.

Диагностика настроек

Тест Гилёва часто используют как индикатор корректности конфигурации операционной системы и сервера баз данных. Вот несколько примеров:

• Энергосбережение Windows. Режим «Сбалансированный» или «Экономия энергии» заставляет процессор снижать тактовую частоту в паузах. Тест Гилёва чувствителен к этому и показывает заниженный результат даже на мощном сервере. Запуск теста мгновенно выявляет проблему.
• Троттлинг из-за перегрева. Если система охлаждения сервера не справляется, процессор сбрасывает частоту. Тест Гилёва показывает резкое падение баллов во время прогона.
• Блокировки в СУБД. В многопоточной части теста низкие результаты могут указывать на проблемы с настройками MS SQL или PostgreSQL — например, на недостаточный размер кэша или неправильную конфигурацию параллелизма.

Что не является целью теста

Важно понимать ограничения бенчмарка. Выделим несколько популярных задач, для которых не стоит использовать тест Гилёва. Далее мы раскроем их подробнее.

Проверка дисковой подсистемы в реальной работе

Тест действительно обращается к диску, особенно в многопоточной части при использовании клиент-серверного варианта. Но это обращение не похоже на реальную нагрузку от сотни пользователей. Тест не проверяет задержки (латентность) при хаотичном чтении, не измеряет IOPS в смешанной нагрузке и не учитывает фрагментацию данных. Высокий балл Гилёва на пустой базе не гарантирует, что диск справится с реальной рабочей нагрузкой в часы пик.

Проверка масштабируемости

Тест не показывает, как поведет себя система при добавлении новых ядер или пользователей. Однопоточная часть вообще игнорирует остальные ядра. Многопоточная часть имитирует ограниченное количество сессий и не масштабируется линейно при росте vCPU на виртуальной машине. Увеличение ресурсов сервера в два раза не приведет к росту баллов Гилёва в два раза — часто результат даже не меняется.

Две части теста Гилёва

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

Однопоточный тест (Core-тест)

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

1С не умеет распараллеливать одну задачу на много ядер процессора. Если у сервера 32 ядра, но каждое из них работает на частоте 2 ГГц, проведение документа всё равно будет использовать только одно ядро с частотой 2 ГГц. Остальные 31 ядро в этот момент простаивают. Именно поэтому для 1С критична не суммарная мощность процессора, а скорость одного ядра. Core-тест Гилёва показывает эту скорость напрямую.

Результаты Core-теста принято оценивать по простой шкале:

• Менее 15 баллов — производительность низкая. На таком сервере тяжелые операции будут заметно тормозить даже при небольшом количестве пользователей.
• От 35 баллов и выше — хороший результат. Система чувствует себя уверенно при типовой офисной нагрузке.
• От 60 баллов и выше — отличный показатель. Такой сервер справляется с самыми требовательными задачами, включая крупные промышленные базы.

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

Многопоточный тест (SQL-тест)

Вторая часть имитирует работу нескольких пользователей одновременно. Тест открывает несколько соединений с базой данных и запускает параллельную запись в регистры. Это ближе к реальной картине, когда утром в систему заходят 20 или 50 сотрудников и начинают вносить данные.

Многопоточный тест косвенно позволяет оценить производительность дисковой подсистемы. Когда несколько потоков одновременно пишут данные, нагрузка на диск растет, и медленный накопитель становится узким местом. Однако результат сильно привязан к конкретной системе управления базами данных. Один и тот же сервер покажет разные баллы на MS SQL и PostgreSQL, даже если реальная скорость работы баз на обеих СУБД одинакова. Сравнивать результаты SQL-теста между разными СУБД бессмысленно.

Эта часть работает только в клиент-серверном варианте. Для файловых баз данных, где 1С сама управляет файлом .1CD без внешней СУБД, запустить эту часть теста не получится. Тест выдаст ошибку или откажется стартовать. Это ограничение заложено в логику бенчмарка — он требует полноценного SQL-сервера для имитации параллельных сессий.

От чего зависит результат тестирования

Результат Теста Гилёва не является константой даже для одного и того же сервера. Изменение одного параметра может поднять баллы с 30 до 60 или, наоборот, обрушить их до 15. Понимание этих зависимостей помогает правильно интерпретировать цифры и не делать ошибочных выводов о производительности.

Частота ЦП

Главный фактор, влияющий на результат Core-теста, — это тактовая частота процессора. Для последовательных операций в 1С скорость расчета напрямую зависит от тактовой частоты одного ядра процессора. Количество ядер при этом почти не имеет значения.

Сервер с 4 ядрами по 4 ГГц покажет в однопоточном тесте результат выше, чем сервер с 32 ядрами по 2 ГГц. Первый выдаст 50–60 баллов, второй — около 20–25, хотя суммарная мощность у второго выше в четыре раза. Это особенность платформы 1С, и тест Гилёва её честно отражает.

Схема питания операционной системы

Режим энергосбережения Windows или Linux способен мгновенно занизить результат теста в два-три раза. Механизм работает так:

• Операционная система по умолчанию стремится экономить электричество
• Когда процессор не занят тяжелой задачей, система снижает его тактовую частоту
• Тест Гилёва создает короткие всплески нагрузки, и система не всегда успевает поднять частоту до максимума за доли секунды

На практике это выглядит как троттлинг — искусственное удержание частоты на низком уровне. Администратор запускает тест на только что установленном сервере и получает 25 баллов вместо ожидаемых 55. Причина почти всегда одна — включен режим «Сбалансированный» или «Экономия энергии». Переключение на схему «Максимальная производительность» мгновенно возвращает честные цифры.

Версия 1С

Существует парадокс, который регулярно путает администраторов. На новых версиях платформы 1С Тест Гилёва часто показывает более низкие баллы, чем на старых. При этом реальная скорость работы может быть выше.

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

Сравнивать результаты теста на разных версиях платформы напрямую нельзя. На версии 8.3.10 и на версии 8.3.25 40 баллов — это разные по сложности достижения. Вторая версия делает гораздо больше полезной работы за те же самые баллы.

Тип системы управления базами данных

Для многопоточной части теста тип СУБД имеет большое значение. Один и тот же сервер с одинаковыми настройками покажет разные баллы на MS SQL Server и PostgreSQL. Разница может достигать 20–30 процентов в любую сторону в зависимости от версии СУБД и конкретной конфигурации.

Однако из этого не следует, что одна СУБД лучше другой для 1С. Тест Гилёва измеряет скорость выполнения специфического набора операций записи в регистр. В реальной работе базы данных большую роль играют другие факторы — оптимизатор запросов, кэширование данных, механизмы блокировок. PostgreSQL может показывать в тесте цифры ниже MS SQL, но при этом быстрее выполнять сложные аналитические отчеты на больших объемах данных.

Сравнивать результаты теста Гилёва между разными СУБД бессмысленно. Это все равно что сравнивать грузоподъемность грузовика и максимальную скорость легкового автомобиля по одним и тем же цифрам. Каждая СУБД оптимизирована под свои сценарии, и тест Гилёва не является универсальным результатом.

Почему тест не подходит для облака

На физическом сервере тест Гилёва — полезный диагностический инструмент. В облачной среде он превращается в источник ложных выводов и неоправданных ожиданий. Причины кроются в самой архитектуре облачных платформ и ограничениях бенчмарка. Далее разберем четыре главные проблемы, которые делают тест бесполезным для оценки реальной производительности в облаке.

Проблема 1. Влияние соседей

В облаке физические ресурсы сервера делятся между несколькими виртуальными машинами. Один физический процессор одновременно обслуживает десятки клиентов. Гипервизор — программа вроде VMware или KVM — распределяет время доступа к ядрам между всеми виртуальными машинами по очереди.

Почему тест не работает в таких условиях:

• Тест Гилёва требует монопольного доступа к частоте процессора
• Тесту нужно, чтобы виртуальная машина получила ядро в полное распоряжение
• Ядро должно удерживаться на максимальной частоте все время теста

В облаке это невозможно. Гипервизор постоянно переключает контекст, отдавая ядро то одной виртуальной машине, то другой.

В итоге результат «плавает» в течение дня:

• Утром, когда соседние виртуальные машины загружены мало, тест показывает 50 баллов
• Днем, когда все клиенты активны, тот же самый тест на той же виртуальной машине выдает 35 баллов

Клиент видит падение и думает, что провайдер урезал ресурсы. На самом деле изменилась только загрузка физического хоста. Тест Гилёва не умеет отличать собственную виртуальную машину от соседей.

Проблема 2. Нелинейность при масштабировании

На физическом сервере добавление ресурсов почти всегда улучшает результат теста. В облаке эта логика ломается. Тест Гилёва не предназначен для работы с виртуальными процессорами и не понимает, как гипервизор эмулирует многопоточность.

В качестве примера можно разобрать частую ситуацию из практики облачного провайдера.

Предположим, клиент арендует виртуальную машину с 4 vCPU и тест Гилёва показывает 47 баллов. Чтобы увеличить мощность, провайдер по просьбе клиента добавляет еще 20 vCPU. В результате повторный запуск показывает 45 баллов — производительность не выросла, а упала.

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

Проблема 3. Завышение показателей файловых баз

Файловый режим работы 1С создает иллюзию высокой производительности. Клиент создает пустую файловую базу, запускает Тест Гилёва и видит фантастические цифры — 120, 150, иногда 200 баллов. Появляется обманчивое мнение, что облачный сервер работает как ракета.

Но реальность в файловом режиме облака выглядит так:

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

Что получает клиент на практике: открытие справочника занимает 10 секунд, проведение документа виснет на полминуты, а постоянные фризы сопровождают каждое действие с базой.

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

Проблема 4. «Пустая» база

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

Реальная база клиента выглядит иначе. Вес может быть 100 гигабайт и даже больше, тысячи справочников, сложные регистры сведений, запланированные задания.

Почему высокий балл ничего не гарантирует:

• На пустой базе операция «Закрытие месяца» выполнится за секунду
• На боевой базе с 100 ГБ данных она может висеть пять минут
• Тест Гилёва не знает о неоптимизированных индексах и блокировках

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

Чем заменить тест в облаке

Раз Тест Гилёва не подходит для облачной среды, возникает закономерный вопрос. Чем измерять производительность? Как клиенту убедиться, что облачный провайдер предоставляет достаточно ресурсов, а сам провайдер может объективно оценить качество своей инфраструктуры? Для этого стоит сменить подход к тестированию.

Есть ряд методов, которые измеряют не абстрактные баллы, а реальную работу системы в условиях, максимально приближенных к боевым. Разберем три таких подхода.

Тестирование на копии реальной базы клиента

Самый надежный способ узнать, как будет работать 1С в облаке, — просто попробовать. Клиент предоставляет копию своей боевой базы, а провайдер разворачивает ее на тестовой виртуальной машине. Дальше запускаются типовые операции — открытие самых тяжелых отчетов, проведение документов, закрытие месяца.

Этот подход называется RUM-метриками (Real User Monitoring). Вместо абстрактных баллов измеряется реальное время отклика системы на конкретные действия пользователя. Цифры получаются честные и понятные. Клиент видит именно то, что получит после переезда.

Мониторинг системных метрик

Ни один синтетический тест не заменит наблюдение за работающей системой в реальном времени. Вместо того чтобы гадать по баллам Гилёва, провайдер и клиент смотрят на конкретные показатели сервера и базы данных.

Что действительно важно отслеживать:

• Latency (задержки). Время, которое проходит между отправкой запроса и получением ответа от диска или от сервера баз данных. Высокие задержки — главная причина тормозов, даже если процессор формально мощный.
• IOPS дисков. Количество операций ввода-вывода в секунду. Для 1С важны не пиковые значения, а стабильность при смешанной нагрузке — когда пользователи одновременно читают и пишут данные.
• Процент использования процессора по времени. Если при реальной работе загрузка ЦП стабильно держится ниже 70–80 процентов, проблема не в процессоре. Если прыгает до 100 процентов на ровном месте — есть смысл копать глубже.

Эти метрики собираются штатными средствами операционной системы и самой платформы 1С через консоль администрирования сервера.

Оценка времени выполнения реальных операций

Самый простой и понятный для бизнеса способ. Берется конкретная операция, которая регулярно выполняется в компании. Это может быть запуск отчета «Анализ продаж» за месяц, проведение документа «Реализация товаров и услуг», выгрузка данных в Excel для дальнейшего анализа и т.д.

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

Этот подход не требует специальных инструментов, но результат дает гораздо более честную картину, чем абстрактные баллы Гилёва.

Заключение

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

Если вы планируете развернуть виртуальную инфраструктуру для работы вашей системы 1С, обращайтесь к специалистам ИТ-ГРАД. Вы получите виртуальную инфраструктуру, которая стабильно держит загрузки, не проседает в часы пик и обеспечивает предсказуемое время отклика без ложных ожиданий и неприятных сюрпризов.

Частые вопросы

1. Правда ли, что Тест Гилёва бесполезен для облачных серверов?

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

2. Почему при добавлении vCPU результат теста не растет или даже падает?

Тест Гилёва изначально проектировался для физических серверов с монопольным доступом к ядрам. В облаке гипервизор распределяет время процессора между несколькими виртуальными машинами. Когда тест пытается нагрузить 24 vCPU одновременно, гипервизор тратит дополнительные ресурсы на переключение контекста. В результате накладные расходы съедают прирост производительности, и тест показывает стагнацию или снижение баллов.

3. Можно ли использовать файловую базу в облаке, если Тест Гилёва показывает на ней отличные цифры?

Технически можно, но не рекомендуется. Тест Гилёва на пустой файловой базе часто выдает 100–200 баллов, что создает ложное ощущение сверхбыстрой работы. В реальности файловая база в облаке страдает от сетевых задержек (латентности) между виртуальной машиной и дисковым массивом. При росте объема данных и количества пользователей это приводит к постоянным фризам. Для облака надежнее и быстрее работает клиент-серверный вариант с отдельной СУБД.

4. Как правильно выбрать облачного провайдера для 1С, если не доверять Тесту Гилёва?

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