Многопоточный тест производительности 1с #658180

Кому интересно: выпущена версия 2.0.001. Тест создает множество фоновых сеансов и выполняет ими одинаковые действия, например создание элементов справочников или запись наборов записей регистров. Он позволяет оценить, насколько "производительна" данная связка 1с - субд, а также насколько она "масштабируема", т.е. количество активных пользователей, при котором система еще будет работать, но "низенько-низенько". Эмпирическим путем получено число в 400-500 попугаев на поток (не учитывая временные таблицы), при котором работа терпима. Благодаря механизму "глобального обмена"  можно повторить тест с чьии-то настройками и сравнить результаты. Полный тест выполняется от получаса до часа на стандартных настройках, примерно в 2 раза меньше на "быстрых" и в 2 раза дольше на "точных". Естественно, проводить не все тесты, то время пропорционально уменьшится. почитать историю версий и скачать можно на (пока на модерации), просто скачать можно на

Кому интересно: выпущена версия 2.0.001. Тест создает множество фоновых сеансов и выполняет ими одинаковые действия, например создание элементов справочников или запись наборов записей регистров. Он позволяет оценить, насколько "производительна" данная связка 1с - субд, а также насколько она "масштабируема", т.е. количество активных пользователей, при котором система еще будет работать, но "низенько-низенько". Эмпирическим путем получено число в 400-500 попугаев на поток (не учитывая временные таблицы), при котором работа терпима. Благодаря механизму "глобального обмена"  можно повторить тест с чьии-то настройками и сравнить результаты. Полный тест выполняется от получаса до часа на стандартных настройках, примерно в 2 раза меньше на "быстрых" и в 2 раза дольше на "точных". Естественно, проводить не все тесты, то время пропорционально уменьшится. почитать историю версий и скачать можно на (пока на модерации), просто скачать можно на

железо:попугаи есть? и какое количество попугаев считается "хорошо" а какое "фиговенько" ?

кое что есть тут (от версии 1): хорошо - это >750 на поток на 4-8 потоках нормально - ~400-500 меньше - плохо. ну и да, надо отмасштабировать на собственное количество активных пользователей

еще бы расширить описание серверов, какая мамка используется, вместе или раздельно, HDD

ну оно от вас зависит. текстовое поле - неограниченной длины

А какая разница, плохо или хорошо? Думаешь если сказать директору, что у нас меньше 400 попугаев, то он тут же отвалит денег на новые компы? Хрен там.

в чем ценность-то? в методике или в инструменте создающем нагрузку?..

методика простая, ценность в инструменте, вернее его многопоточности.

Я обратил внимание на то, что на СКЛ2005 первая версия тест выполнялась с лучшими показателями, чем на 2008R2 и 2012.

а еще на постгре нет проседания по РС, что тоже интересно

У меня сложилось мнение, что нормально - это 750-1000, хорошо 1000-1500, отлично - выше 1500. 820 на поток при 8 потоках выдает обычная виртуальная машина с нетюнингованной ОС, СКЛ и сервером предприятия, лежащая на обычном сата-диске.

в старом тесте значительно сильнее было влияние того, находится ли скуль и 1с на одной машине, или нет. сейчас такая ситуация примерно если поставить "маленькие" объекты. Но когда они на одном сервере - проседание начинается раньше и оно больше. если на разных - вплоть до того, что проседания нет

ну и да - понимание того, что есть нормально у всех разное :) у нас 130 пользюков работает на сервере с графиком из вполне себе. Жалуются - да, но я бы не сказал, что все "зверски" тормозит

правда активными этих пользователей сложно назвать

А в чем смысл? ИМХО все эти тесты годятся только для того чтобы выяснить у кого длиннее. На реальной нагрузке будет все совсем по другому, ибо тут и от кода зависит, и от базы,  и от режима работы пользователей.

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

славно завтра новый стенд "помучаю"

А с ФР согласована реклама? :-)

ФР это кто? Фискальный Регистр?

давай, а то сравнивать несчем

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

потому что они за файрволлом, завтра будет время - локально вебсервак разгоню - и тогда сделаю замеров пачку

зато знаете, как прикольно отлаживать SOAP на пхп, когда нету возможности повызывать его почеловечески :)

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

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

только у меня на тестах, пришедших по обмену код не выставляется?

нет не только

исправил, обновил на сайте и на инфостарте (пока на можерации) до версии 2.0.002. можно просто обновить конфу - добавлена обработка обновления, которая перенумерует коды справочника. После открытия почему-то отображается необновленной, надо нажать "обновить"

добавил два своих результата - на тестовом коре дуо и на боевом ксеоне

Раньше тест работал веселее. В процессе работы отображал результаты. Сейчас просто ушел в себя и всё.

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

{Справочник.Тесты.Форма.ФормаЭлемента.Форма}: Поле объекта не обнаружено (ПрофилиРезультатов)

ой :)

обновил до 2.0.003 с исправлением - это я снял галочку "использовать всегда" с таблицы "профиль результатов". Эта таблица показывает распределение по времени ОДНОЙ операции, может показать "выбросы", например

ну что, как там?

автообновления конфиги как в типовых когда ждать?

pfgbcfk d dbikbcn

записал в вишлист

обновил до 2.0.004 (на сайте, на ИС - на модерации). Исправлена ошибка работы на платформе 8.2.14

На файловой работает? У меня ругается, что "менеджер заданий не активен"

файловая к версии 2.1 будет. но вряд ли оно будет работать в 112 потоков

А зачем тогда стоит выбор файлового варианта? :-)

просто все варианты :) А так - никто не мешает тебе на файловой скачать результаты с сайта.

А зачем мне чужие результаты?

посмотреть на размер чужих писек, например, если задумываешь апгрейд или выбираешь, какой сервер СУБД использовать, или там, ставить на 1 комп сервер 1с и СУБД или нет. К сожалению, пока результатов не много, а на ДБ2 - так вообще ни одного отчета нету :(

интересные результаты в комментах на ИС:

До 9го мая будут на дб2

будет здорово, если на той же машине еще тест на постгре/мсскуле сделаешь

нет, не сделаю... нет там ни того ни другого

жалко. ну хоть на кривую посмотрим.

УПП 60 fps дает?

тестить УПП и прочие конкретные конфы надо с помощью тестцентра. данный тест предназначен именно для тестов железа/субд/сервера 1с.

Переделал обмен - теперь сайт выплевывает по 10 результатов, надо нажимать на кнопку обмена несколько раз, пока не перестанут приходить новые результаты (поступили сообщения о том, что обмен не работает, видимо, при формировании XML упирался в лимит памяти).

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

почему rmngr столько жрет?

по поводу есть мысли?

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

лучший тест 100 набивальщиц расходных накладных.

никогда не ставил 1ску в магазине на 20 касс?

нет, мене достаточно 20 манагеров на производстве

к слову никогда не делал базу ЖКХ на 20 тыр клиентов, на п1 64 мб ?

а расчет зп на 7 тыр на ес ?

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

была практика ?

на 7.7 мини ЗП на оборотных РН было, правда давно

Сейчас в тесте из используется синхронизация старта вычислений в потоках через установки управляемой блокировки на константу - такой способ показал лучший результат по сравнению с "примерной паузой на время запуска" - 112 потоков на одном сервере синхронизируются за 300-400мс (для ненагруженного сервера). Однако проводя исследования масштабируемости кластера 1с выяснилось, что данный способ неудовлетворителен при использовании нескольких физических серверов 1с, объединенных в 1 кластер: для 16 потоков 1 сервер 1с показывает синхронизацию за 30-50мс, 2 сервера 1с в кластере, соединенные гигабитом 250-300мс, для 64 потоков: ~200мс и 8 секунд (это максимальное время, среднее 180мс и 1 секунда) для 128 потоков: 400мс и 15 секунд соответственно. при этом "одинокий" сервер слабее любого из 2-х в "двойном" кластере. Вопрос знатокам - каким образом обеспечить приемлемую синхронизацию старта вычислений в разных потоках в кластере из нескольких физических серверов 1с? ведь чем больше разброс старта - тем меньше потоки работают одновременно и менее показателен тест. Будет ли приемлемо использование внешнего "синхронизатора" (который потребует установки доп. софта), будете ли вы пользоваться тестом в таком случае?

Релиз ядра Linux 3.10 Главным образом это интересно из-за такого изменения: В ядро интегрированы наработки ветки 'ipc-scalability', в которой проведена работа по чистке и увеличению масштабируемости реализации SysV IPC. В частности, переработана система организации блокировок. Если ранее поддерживалась установка одной ipc-блокировки на массив семафоров, то теперь блокировки более гранулированы и могут быть установленных для отдельных семафоров. В итоге, некоторые тесты производительности показывают прирост производительности при работе с семафорами до 10 раз. Прирост производительности в тесте Pgbench составил 100%; Внесены оптимизации в код семафоров чтения и записи (rwsem), что позволило заметно повысить производительности для некоторых типов нагрузки. Например, прирост производительности в тесте Pgbench составил 100%; У кого на линупсе/постгре крутится - по идее в многопользовательском режиме должно лучше стать. Буду благодарен, если кто-нибудь проверит, есть ли изменения.

фу спамер

это цитата из анонса

Если действительно интересно, пиши в личку. Готов поделится информацией.

Господа, можно ли провести аналогию данного теста с функциональностью Тест-центра 2.03? Интересует: 1. Можно ли тестировать производительность конкретного параметра ПК, например дисковую подсистему (насколько быстро создаются индексы в базе MS SQL при вставке и сохранении новых значений)? 2. Существует ли возможность детектить дохлые блокировки (dead locks), как в Тест-центре? 3. Существует ли возможность модернизации теста за счёт запуска заранее сохранённого сценария (например, через SQL Profiler)?

тест центр предназначен для тестирования конкретных конфигураций путем эмуляции работы пользователей. с одной стороны - это хорошо, так как результаты получаются более приближенными к "реальности", но с другой стороны - он требует исследования характера нагрузки и правильной скурпулезной настройки - подготовки данных, очистки за собой и т.п. конфигурация из - это синтетический тест, который показывает потенциальную производительность и масштабируемость системы, т.е. просто это немного другой инструмент, он ближе к тесту TPC от Гилева, но он многопоточный :). Если этот тест показывает при 16 потоках 1000 баллов на поток, а тестцентр, прикрученный к работающей конфигурации - показывает дедлоки и кучу ошибок, или при реальной работе десятка пользователей возникают эти самые дедлоки и ошибки - то тут становится понятно что сама конфигурация написана очень неоптимально и есть, что менять и куда расти. ну а дедлоки при работе теста возникнуть вроде как не могут (по крайней мере на практике ни одного раза не возникли).

Спасибо. Очень подробно описали. Постараюсь использовать в работе.

>>У кого на линупсе/постгре крутится - по идее в многопользовательском режиме должно лучше стать. Буду благодарен, если кто-нибудь проверит, есть ли изменения. Проверил, не стало, ни на твоем тесте, ни на тесте Вячеслава(Гилева). Результаты один в один на разных ядрах. Правда, проверялось на обычном десктопе, не самом свежем к тому же. СУБД+сервер приложений+клиент платформы 8.3.3.658. Ядра 3.8.13 и 3.10.0 память 8 ГБ, процессор i3-2130 3.4 GHz. Так что ускорение откладывается, для 1С, по крайней мере. Надо будет еще бухгалтерию погонять, может перепроведение какое-нибудь побыстрее будет...

если есть UPS - можно в fstab прописать barrier=0 для раздела с базой - должно помочь при большой нагрузке

в качестве апа и чтобы ветка не протухла - теперь я считаю, кто у меня скачал конфигурацию...

В результатах тестов убрана колонка "номер потока", теперь результаты хранятся только в разрезе количества потоков теста. Это в десятки раз сократило количество строк в ТЧ Результаты и Профиль Результата, так что теперь собственные тесты открываются с такой же скоростью, как и тесты, полученные из интернета (ранее была задержка в несколько секунд, в результатах интернета для сокращения трафика изначально информация о номере потока была опущена изначально). Также немного ускорилось формирование отчетов. Исправлены ошибки при запуске в режиме "Толстый клиент управляемое приложение". При запуске в этом режиме интернет на сервере не обязателен для обмена. Если вы делаете обновление, то теперь возможно обновление только с версии >= 2.001 (при попытке обновления версии 1.х.ххх будет ошибка). Возможно позже сделаю поставку, чтобы корректно это контролировать.

хотя про интернет я не уверен, админы у нас оказывается разрешили инет на серверах...

Не думал о том чтобы прикрутить сбор минимальных данных о системе? Ось, разрядность, процессор, диск? Для наглядности сравнения?

минимальные данные сервера 1с - снимаются

как получить данные сервера СУБД - оно хз

perfomanceTest_2.0.007 {ОбщийМодуль.ОбновлениеКонфигурации.Модуль}: Ошибка при вызове метода контекста (Выполнить) по причине: {(7, 21)}: Поле не найдено "Тесты.Результаты._УдалитьТест"

мля, счас поправлю

поправил, перегрузите .cf-ку

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

проверил :)

Отчет по тесту (все значения - "по умолчанию") - кнопка "Сформировать": Ошибка при исполнении запроса набора данных по причине: {(12, 29)}: Не задано значение параметра "Ссылка" И ТестыРезультаты.Ссылка = <<?>>&Ссылка После показа панели ошибки и нажатия кнопки "Завершить" - аварийный выход из программы. Платформа 8.2.18.104, толстый клиент. "Баланс точность/время:" - наименования значений, имхо, лучше будет если типа "низкая/быстро", "оптимальный", "высокая/долго" "Размер создаваемых объектов" - "минимальный", "средний","большой"...

отчет по тесту - он по тесту :) установи значение параметра или запускай его из формы списка/элеамента тестов

а вот почему аварийный выход - непонятно

Настройка теста - Выбор значения "Ссылка" - невозможен. Панель - есть, список - заполнен, кнопка "Выбрать" - выход, значение не выбирается (не заполняется в настройке)

опа, и правда... кажется я там что-то с множественным выбором накосячил. сегодня ждите 2.0.009 а пока пользуйтесь кнопками в меню "создать на основании"

+ Из списка тестов, по кнопке "создать на основании" - все пункты подменю работают корректно.

"Выполнить тест" После сообщения - "Старт теста Регистры бухгалтерии в 4 потоков" ошибка: {ОбщийМодуль.Тестирование.Модуль}: Ошибка при вызове метода контекста (ОжидатьЗавершения)     ФоновыеЗадания.ОжидатьЗавершения(МассивЗаданий); по причине: Выполнение одного или нескольких заданий завершилось с ошибкой

Продолжаю третировать тест (и автора) :) Не совсем понятная ситуация: Действие "Записать и выйти" при сохранении нового теста с галочкой "Сервер1С" и без галочки "Сервер СУБД": Предупреждение "Пожалуйста, заполните информацию о серверах". Вообще-то тестируется только один сервер. Ну ок, жму кнопку "Согласен" - действие "Записать и закрыть" отменено... и с чем я был только что "согласен"? И что должно было быть далее и что мне с этим делать? :)

поставить галочку "сервер СУБД", если это один сервер с сервером 1с или добавить строку и в ней уже прописать параметры сервера СУБД

но, конечно, конструктивная критика всегда полезна

Когда запускаешь тест в рабочеевремя (во время работы серверов с пользователями), очень часто тестирование генерит сообщение "Не получилось синхронизировать потоки за 30 секунд!" (общий модуль Тестирование, стр.54) Также очень часто возникает ошибка (написанная тоже с ошибкой:) - "Деление на 0ОбщийМодуль.Тестирование.Модуль599"

Такое может возникать, когда запущено много рабочих процессов, даже когда тест выполняется в 2-4 потока. А один рабочий процесс больше 48-и потоков не тянет(у меня, по крайней мере), сервер приложений наглухо подвисает(при одном пользователе). Пробовал с 4-мя рабочими процессами на 16 ядер без HT, остановился на 2-х,  так синхронизация проходит. Для работы, конечно, хватает и одного рабочего процесса.