Комментарии 15
Картинки с мелким текстом лучше бы сделать кликабельными.
В начале есть утверждение:
Стоит понимать, что тест Гилева никак не отражает быстродействие реальной конфигурации с реальной базой данных.
Очень надеялся увидеть хоть какие-то реальные подтверждения в тексте статьи. А их и нет. И как итог, утверждение начинает выглядеть голословным.
У вас явно нет понимания области применения синтетических и индивидуально написанных тестов под конкретную базу. Ни какой синтетический тест не будет отражать вашу индивидуальную операцию 1 в 1, да это и не требуется. Задача синтетического теста сделать первую быструю экспресс оценку без вкладывания больших сил и денег.
Тест однопоточный потому что большинство OLTP операций в 1С выполняются однопоточно и тест достаточно показателен для большинства баз небольшого размера.
Есть другие тесты, например "объемные тесты", которые решают схожие задачи, но они тоже достаточно индивидуальный, и нет цели всем налево и направо их делать.
Понятно, что вы в 1С можете написать вообще уникальный код и говорить что он не коррелирует с нашим тестом. Но тут же вопрос репрезентативности выводов. Ну и толку что вы оцените свою уникальную операцию, да для вас это будет полезно, а остальным сильно интересно знать скорость операции, которая у них никогда выполняться не будет?
"на сайте авторов имеются рекомендации, хотя и неполные и отчасти устаревшие" — давайте конкретней, чего нет? многие вещи мы отвечаем в форуме, я сомневаюсь что вы его целиком перечитали.
"Как можно увидеть, значительного выигрыша в результатах теста Гилева увеличение количества виртуальных процессоров не даёт." — вы явно не понимаете область применения теста
если вы хотите тестировать количество соединений/сеансов, количество одновременных фоновиков и т.п. то вам надо делать не синтетический тест, так как он все равно не будет учитывать блокировок в вашей реальной базе, а индивидуально написанный тест.
но даже в этом случае нашим тестом вы видите скорость одного потока, и если там скажем 8 баллов то и многопоточный тест на такой железки хороших результатов не выдаст
"Как можно увидеть, увеличение памяти не даёт ощутимого влияния на результаты теста." — вот тут очень спорное утверждение — если вы нарезаете в виртуалке гигабайт и он физически выделаяется на той же планке памяти то с какого перепугу будут изменения? их не будет. А вот если вы втыкаете к существующим планкам еще новые — наши замеры показывают ухудшение скорости. И это связано с падением частоты на планках памяти что можно объективно замерить вне нашего теста специализированными инструментами.
Ну и напоследок по замерам на вашем ноутбуке. Внедряйте апдекс и демонстрируйте реальные цифры. Я уверен что ваши реальные операции ведут себя по разному по отношению к друг другу. Может быть так что одни значительно ускорятся, другие очень мало, а третьи вообще не ускорятся. Вы же делаете очень субъективную оценку с далеко идущими выводами.
Многие тестируют нашим тестом потому что остальные жмутся что то сделать достойное и бесплатно.
И да, вы ругаете тест, но альтернативы не предлагаете. Поверьте, я тоже так могу )))
Я всего лишь рассказал о своей конкретной ситуации, где двухъядерный ноутбучный процессор 8gb DDR3 и sata ssd показывает лучшие результаты в тесте, чем 2 8 ядерных серверных процессора с 64gb DDR4 и SAS ssd.
Добрый день. Как может Ваш тест показывать примерно 12 на виртуальном сервере с 16 процессорами, SSD диском, 30 Гб памяти, SQL база и 47 на том же железе в файловой базе? Ответ только один - тест однозначно писался для файловой базы. Никакие настройки производительности системы, SQL сервера и сервера 1С8 не дают изменений. Для сравнения на гораздо более слабом сервере - 4 ядра, 6 Гб памяти, HDD, SQL база, без всяких оптимизаций и настроек - 28, но я уверен, что при работе хотя бы 10-15 пользователей всё будет очень грустно, а при работе 30-50 пользователей на первом сервере всё будет в порядке.
приходите на наши курсы, расскажем-покажем
Что интересно - в варианте SQL не важно, какие диски в системе и где что расположено - тест не обращается к дискам, в самом начале загружается в память, соответственно, влияет только частота процессора и памяти, но тогда непонятно - почему на слабой ВМ на VirtualBox результаты чуть выше, чем на гораздо более мощной ВМ на мощном железе - примерно 15 против 12 при просто несопоставимых ресурсах серверов.
Соответсвенно - особенно что-то настраивать для получения более высокого результата кроме настроек планов питания в гипервизоре и ВМ особенно нечего - никакие пляски с сервером 1С и MS SQL на результат теста не влияют, надо проверять на проведении документов в реальных базах.
тонкую настройку параметров баз model
А что можно настроить в model?
Для совместной архитектуры отключили все протоколы обмена данными, кроме shared memory
Сервер СУБД и приложений были на одном хосте кластера?
К сожалению, все картинки нечитаемые — низкое разрешение.
Установили максимальную степень параллелизма равную 1
Включите unsafe writeback, отключите spectre mitigations в гипервизоре, включите hyperthreading, и, вуаля, у вас отличный бенчмарчонок. До первого залётного дятла всё будет летать. После тоже, но только в направлении ускорения свободного падения.
Разносить файлы баз по дискам — это правильно. Для чистоты эксперимента надо ещё и диски по разным контроллерам разнести.
Виртуальные машины и тест Гилева