Комментарии 12

Картинки с мелким текстом лучше бы сделать кликабельными.


В начале есть утверждение:


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

Очень надеялся увидеть хоть какие-то реальные подтверждения в тексте статьи. А их и нет. И как итог, утверждение начинает выглядеть голословным.

Но ведь утверждение не голословное. На старом сервере тест показывает 10.6. На новом 11.8. На ноуте 24. 1С упп на 80 пользователей на старом сервере работает приемлемо, на новом — летает. На ноуте, понятно, не запускали, но даже один пользователь работает существенно медленнее, чем на новом сервере.

У вас явно нет понимания области применения синтетических и индивидуально написанных тестов под конкретную базу. Ни какой синтетический тест не будет отражать вашу индивидуальную операцию 1 в 1, да это и не требуется. Задача синтетического теста сделать первую быструю экспресс оценку без вкладывания больших сил и денег.
Тест однопоточный потому что большинство OLTP операций в 1С выполняются однопоточно и тест достаточно показателен для большинства баз небольшого размера.
Есть другие тесты, например "объемные тесты", которые решают схожие задачи, но они тоже достаточно индивидуальный, и нет цели всем налево и направо их делать.
Понятно, что вы в 1С можете написать вообще уникальный код и говорить что он не коррелирует с нашим тестом. Но тут же вопрос репрезентативности выводов. Ну и толку что вы оцените свою уникальную операцию, да для вас это будет полезно, а остальным сильно интересно знать скорость операции, которая у них никогда выполняться не будет?
"на сайте авторов имеются рекомендации, хотя и неполные и отчасти устаревшие" — давайте конкретней, чего нет? многие вещи мы отвечаем в форуме, я сомневаюсь что вы его целиком перечитали.
"Как можно увидеть, значительного выигрыша в результатах теста Гилева увеличение количества виртуальных процессоров не даёт." — вы явно не понимаете область применения теста
если вы хотите тестировать количество соединений/сеансов, количество одновременных фоновиков и т.п. то вам надо делать не синтетический тест, так как он все равно не будет учитывать блокировок в вашей реальной базе, а индивидуально написанный тест.
но даже в этом случае нашим тестом вы видите скорость одного потока, и если там скажем 8 баллов то и многопоточный тест на такой железки хороших результатов не выдаст
"Как можно увидеть, увеличение памяти не даёт ощутимого влияния на результаты теста." — вот тут очень спорное утверждение — если вы нарезаете в виртуалке гигабайт и он физически выделаяется на той же планке памяти то с какого перепугу будут изменения? их не будет. А вот если вы втыкаете к существующим планкам еще новые — наши замеры показывают ухудшение скорости. И это связано с падением частоты на планках памяти что можно объективно замерить вне нашего теста специализированными инструментами.
Ну и напоследок по замерам на вашем ноутбуке. Внедряйте апдекс и демонстрируйте реальные цифры. Я уверен что ваши реальные операции ведут себя по разному по отношению к друг другу. Может быть так что одни значительно ускорятся, другие очень мало, а третьи вообще не ускорятся. Вы же делаете очень субъективную оценку с далеко идущими выводами.
Многие тестируют нашим тестом потому что остальные жмутся что то сделать достойное и бесплатно.
И да, вы ругаете тест, но альтернативы не предлагаете. Поверьте, я тоже так могу )))

Непонятно почему вы принимаете меня за автора статьи.
Я всего лишь рассказал о своей конкретной ситуации, где двухъядерный ноутбучный процессор 8gb DDR3 и sata ssd показывает лучшие результаты в тесте, чем 2 8 ядерных серверных процессора с 64gb DDR4 и SAS ssd.
тонкую настройку параметров баз model

А что можно настроить в model?
Для совместной архитектуры отключили все протоколы обмена данными, кроме shared memory

Сервер СУБД и приложений были на одном хосте кластера?

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

Включите unsafe writeback, отключите spectre mitigations в гипервизоре, включите hyperthreading, и, вуаля, у вас отличный бенчмарчонок. До первого залётного дятла всё будет летать. После тоже, но только в направлении ускорения свободного падения.

Разумеется, CI прямо просит unsafe writeback. Но вот dev-базы… Вот писал человек конфигурацию, шмяк, ребут, вместо написанного какашка. Обидно?

Разносить файлы баз по дискам — это правильно. Для чистоты эксперимента надо ещё и диски по разным контроллерам разнести.

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Информация

Дата основания
2009
Местоположение
Россия
Сайт
www.cloud4y.ru
Численность
31–50 человек
Дата регистрации

Блог на Хабре