Почему фоновые задачи так тормозят? #690391

Пробую перевести файловую БП3 на клиент-сервер. В клиент-сервере, как известно, для выполнения стандартных отчетов и регламентных процедур закрытия месяца _безальтернативно_ используется механизм фоновых заданий. С одной стороны, это плюс - позволяет во время формирования отчета пользователю делать что-то еще, но есть одно НО - огромный оверхед по времени выполнения при использовании этого механизма. Так, оборотно-сальдовая ведомость, которая формируется за секунду в файловом режиме, в режиме отложенного выполнения заданий формируется порядка 8 секунд. И проблема тут не собственно в клиент-сервере. Попробовал "обмануть" конфигурацию, заставив её подумать, что она работает на файловой версии (добавил в начало функции ОбщегоНазначения.ИнформационнаяБазаФайловая строчку Возврат Истина;) - в этом случае отчет выполняется на sql-базе так же быстро, как и в файловой. Вопрос. Почему такие задержки при использовании фоновых заданий?

Попробовал в виде эксперимента подкрутить в конфигурации тайминги опроса фонового задания, в ДлительныеОперацииКлиент.ИнициализироватьПараметрыОбработчикаОжидания и в ДлительныеОперации.ЗапуститьВыполнениеВФоне указал 0.1 секунду без последующего увеличения - резко выросло количество вызовов сервера, однако скорость формирования не изменилась... странно как-то. На что тратится время?

что собщает замер производительности ?

время тратится на ожидание выделения процессорного времени ОС..

Процессорного времени ОС в избытке и на сервере и на клиенте. Или вы имеете в виду, что 1с запускает для каждого фонового задания отдельный процесс? Неужели так всё плохо?

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

сколько процессов на сервере 1С?

8 рабочих процессов (по количеству ядер). Загруженность сервера близка к нулю.

оставь 1 процесс

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

да, плохо что 32-битный, но, помню, у одного клиента помогло

а если процесс фоновых заданий вынести в отдельный менеджер?

Попробовал всем процессам, кроме одного, поставить "Не использовать", пока не удаляя их - скорость инициализации фоновых задач резко выросла. Теперь 2 секунды вместо 8. Спасибо за подсказку.. не ожидал от 1с такой подлянки.

Поставь разрешить отладку на сервере И в конфигураторе Отладка Подключение автоматическое подключение фоновые Сделай замер Но вообще не понятно зачем нужно ускорять фоновые ?

Верни назад, не нужно ускорять иниц фоновых

он же написал зачем, чтобы не ждать оборотку по 8 секунд, а ждать по 2.

Ну может 1С решает, какому процессу отдать выполнение фонового.

Ну ну удачи ему в его экспериментах Про параллельность и приоритеты я так понимаю пофиг

Если бухгалтер запустил формироваться ОСВ - он будет ждать, пока она сформируется.. ему параллельность нафиг не нужна, ему важнее реактивность интерфейса

А зачем в фоне делаешь ?

Мне незачем. Просто 1с выбора не оставляет: любой стандартный отчет БП3 формируется в фоновом режиме, если конфигурация запущена на клиент-сервере. Так задумано в 1с.

писатель

И там одну строку переписать ?

И это будет уже не типовая, а так да..

"Ну может 1С решает, какому процессу отдать выполнение фонового" Уж слишком она задумчива в этом самом месте. Чтобы выбрать один из 8 - тратит не менее 5 секунд. Она на счетах что ли считает?)

а сколько запускается пустое фоновое задание?

просто тупо через менеджер фоновых + ожидать завершения на пустую функцию?

Или отчет на СКД самый примитивный типа Выбрать элемент справочника с отбором по коду

Попробовал с предопределенным заданием "Обмен сообщениями по учетным записям документооборота", поскольку сообщений никаких нет - на одном РП выполняется моментально (менее секунды), на более чем одном (проверял от 2 до 12) - задержка 8 секунд. В общем вывод такой - тормоза при использовании нескольких рабочих процессов, причем нет ощутимой зависимости от количества РП больше одного.

Так уже давно грят что чем меньше процессов тем лучше ?

Спорный вопрос. Как один рпхост сможет использовать возможности многопроцессорного сервера?

может

Осталось проверить то же самое для 100 юзверей

В любом случае баг с тормозами запуска ФЗ при нескольких РП остается багом. 8 секунд плюсом на запуск - они не лишние при сколь угодно большом количестве пользователей..

Вот представь - что кроме того что выполнить задачу нужно породить задание, определить нагрузку подчиненных, расчитать приоритеты, выделить ресурсы, согласовать параллельное получение данных и т.д. и только потом выполнить задачу Что быстрее ?

Это лишь слова. А на деле - задача сводится к выбору одного наименее нагруженного процесса. Тратить на это несколько реальных секунд на современном сервере по меньшей мере неразумно.

Кстати, говорят в 8.3 вообще убрали возможность добавлять рабочие процессы.. видать неспроста

неявно - можно. можно сказать что два пользователя на один рабочий процес, или 1 база

Ну исходников 1Сного сервера мы не имеем и по этому как они там реализовали работу всей этой кухни понятия не имею ! Но 1С любит экспериментировать, это факт !

Как написали ниже кухни мы не знаем. Может там идет инициализация которая потом исчезнет. Опять же большое количество данных между процесссами перекидывается не мгновенно

Вообщем проведи тест на 100 чел для вывода

багоискаители :), там обработчик ожидания опрашивает фоновые задания на предмет выполнение с определенной периодичностью :)

я у автора спросил за что-то типа Задание = ФоновыеЗадания.Выполнить("ФоновыеФункции.ФоноваяКалибровка"); и обработчик ожидания тут не причем

лишь бы ляпнуть

модуль ДлительныеОперации ВЫЗОВ: в общей форме "ФормаОтчета", процедура Функция ОтчетСкомпоноватьРезультатНаСервере(ВФоновомЗадании) ........... ........... Попытка                 ПараметрыФормированияОтчета,                 НСтр("ru = 'Варианты отчетов: Формирование отчета'")             ); ПРОВЕРКА: иногда лучше промолчать

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

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

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