Business Connector и его сессии

[Sergey Petrov]

Коллеги, добрый день!

Есть вопрос по практическому использованию Business Connector для DAX 2009.

Мы сейчас реализуем связь DAX 2009 и Битрикс 24 через .Net Business Connector.
Реализация с использованием Web API (IIS + ASP.NET + C#).
Имеет ли смысл постоянно держать одну открытую сессию для Business Connector в DAX 2009, чтобы через неё выполнять все внешние запросы? Есть ли вообще такая возможность?
Сейчас реализация следующая: каждый запрос к Web API создаёт свой экземпляр Business Connector, для него открывается отдельная сессия в DAX 2009, в рамках которой выполняется статический метод в контексте DAX. Как только результаты получены на стороне Web API, сессия закрывается и экземпляр Business Connector прекращает осознанное существование. Есть определённые сомнения, что такой алгоритм не будет продуктивен при промышленной эксплуатации и мы получим проседание по производительности из-за траты ресурсов на открытия-закрытия сессий DAX.

Поделитесь опытом, пожалуйста.

[Weez]

Добрый день, использую Business connector в той же конфигурации, что вы описали. Написали свой вебсервис, при обращении к которому через сессию бизнес-коннектора вызывается статик метод с параметрами в аксапте. Никакой проблемы с производительностью не замечал, правда обратил внимание что сейчас существует открытая сессия бизнес-коннектора в активных пользователях, хотя запрос выполнялся довольно давно. Можно, скорее всего, принудительно закрывать сессию - но смысла особого не вижу, и так работает стабильно.

[_scorp_]

Добрый день.

С точки зрения производительности мы пришли к следующему решению: Есть web-сервис, к которому могут обращаться внешние приложения. У web-сервиса есть пул бизнес коннекторов с открытым подключением (размер пула прописываем в web.config). Если в web-сервис приходит какой-то запрос - смотрим в пул - есть там свободный BC или нет, если есть, то запрос его забирает, выполняет с ним обращение к AX и возвращает в пул (пул его принимает если размер пула не максимальный). Если в пуле свободного BC нет - создается новый BC => устанавливается соединение к AX => вызывается какая-то логика в AX => попытка положить BC в пул. Если в пуле максимальное число доступных BC - закрываем соединение с AX. Если пул не полный - не закрываем соединение для BC и кладём его в пул. Несколько раз в день на периодической основе пул "рефрешим" (на всякий случаем переоткрываем соединения для BC в пуле).

[Raven Melancholic]

Цитата:

Сообщение от Sergey Petrov

Есть определённые сомнения, что ... мы получим проседание по производительности из-за траты ресурсов на открытия-закрытия сессий DAX.

Если Вы заметили, то у Business Connector есть два вида сессий.
Одна имеет тип «Рабочий», она относится к процессу в целом и в ней загружаются какие-то постоянные данные (типа приложения, каких-то библиотек и т. п., что именно там загружено изучать пока не было потребности). То есть, в первое обращение процесса (Windows службы, IIS и т. д.) к Business Connector создает эту сессию и подгружает все эти данные. Такая сессия существует до тех пор, пока процесс не завершился, ну или бывает, что планировщик может решить что процесс давно не выполняет действия и выгрузить процесс из памяти, тогда и сессия соединения с DAX «Рабочий» пропадает.

На этот тип сессии мы не влияем, как понимаю, речь идет о сессиях, которые создаются в момент обращения конкретного подключения для выполнения работы. Обычно работа происходит примерно так:

• Axapta.LogonAs
• Вызов Axapta.Чего-то-там.
• Axapta.Logoff();

Насколько понимаю, вопрос в том, нужно ли использовать указанный подход и на каждое обращение делать указанную цепочку или сделать Axapta каким-то статическим Singleton и использовать его, открыв один раз.

Тут следует учесть, что LogonAs выполняется намного быстрее, чем создание первого коннекта «Рабочий», поэтому все зависит от частоты обращения к бизнес-логике. Если такие обращения идут 1-2-3-4 раза в минуту, то что-то городить нет смысла, справимся и при классическом подходе.

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

А вот если запросов много, компания одна, то постоянное соединение может дать выигрыш. Но есть нюанс: мы же многозадачные, поэтому соединение должно быть не одно. И тут помогает то, что предлагает _scorp_ - пул соединений.

То есть, есть какой-то пул открытых соединений, при обращении за бизнес-логикой вызывается не Axapta.LogonAs, а запрашивается соединение из пула, а уже пул решает есть ли у него свободные соединения, можно ли отдать такое соединение или нужно создать новое, сам пул обслуживает открытые соединения и если они долго не используются закрывает их, определяет «зависшие» соединения и т. п.

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

[trud]

Цитата:

Сообщение от Raven Melancholic

А вот если запросов много, компания одна, то постоянное соединение может дать выигрыш.

То есть, есть какой-то пул открытых соединений, при обращении за бизнес-логикой вызывается не Axapta.LogonAs, а запрашивается соединение из пула, а уже пул решает есть ли у него свободные соединения, можно ли отдать такое соединение или нужно создать новое, сам пул обслуживает открытые соединения и если они долго не используются закрывает их, определяет «зависшие» соединения и т. п.

Кстати интерестно - а вы тестировали подобный подход(что пул будет давать какой-то выигрыш) или это просто размышления? Мне казалось что АОС уже сам делает что-то подобное, хотя возможно зависит от версии. Ну и надо тестировать конечно же

[Logger]

Цитата:

Сообщение от trud

Кстати интерестно - а вы тестировали подобный подход(что пул будет давать какой-то выигрыш) или это просто размышления? Мне казалось что АОС уже сам делает что-то подобное, хотя возможно зависит от версии. Ну и надо тестировать конечно же

Com коннектор в 2009-й точно не делает. Я проверял.
Возможно ли кешировать COM соединения в PHP ?
там периодически подвисания идут при логине на весьма прогретом сервере под нагрузкой.

.Net не замерял, но сомневаюсь что делает.

[Raven Melancholic]

Особо сверхточных измерений с использованием каких-то инструментов не делал. Реализация была для DAX2009 из внешней WEB службы на C#, работающей на IIS. Для DAX4 это была Windows служба, так же написанная на C#.
Было просто:
1. С службе перед входом в цепочку писался лог.
2. В DAX в начале статического метода писалось в свой лог.
3. В DAX в конце метода писалось в свой лог.
4. В службе после окончания цепочки писался лог.
Потом в Excel компоновал эти логи. Смотрел на время между 1-2 и 3-4.
Конкретные цифры не помню, логов этих не сохранилось В целом сокращение при использовании пула было суммарно в районе секунд. Что интересно, что сокращение для 3-4 было больше, чем для 1-2, то есть, получалось что отключение более тормозное, чем коннект.
Ну, главное, что пользователи стали меньше жаловаться на подвисания.
Тут еще есть особенность - сама работа в DAX была короткой, оптимизировано там было здорово, специально вместо длинной операции делались несколько коротких, поэтому разница визуально была заметна. Понятно, что если сама обработка в DAX будет долгой, то наверное выигрыш не будет стоить усложнения.

[Logger]

А в моем случае было так.
Был сканер на складе, который на каждом пике в php создавал com объект аксапты, делал коннект и получал / отправлял какие-то данные. Со стороны юзеров было требование, что длина пика не должна превышать 1 сек. Реально на прогретом приложении все укладывалось в 100-200 миллисекунд. Но периодически были выбросы до нескольких секунд и иногда довольно частые. Юзеров это сильно нервировало.

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

[Sergey Petrov]

Коллеги, провёл эксперимент - вызывал пустой тестовый метод заданное количество раз подряд. Второй эксперимент - из двух браузеров параллельно запускал вызов того же самого тестового пустого метода, чтобы посмотреть на внутреннюю конкуренцию при параллельных коннектах.
Вывод - время выполнения задания увеличивается практически линейно с увеличением количества повторов (100 - около 3 секунд, 1000 - за 35 секунд). То есть, на одно подключение - порядка 0,03 секунды, нет задержек, связанных с накоплением ожидания каких-то ресурсов. При параллельном выполнении задания из двух браузеров результаты остались неизменны. То есть, параллельные подключения и отключения также не влияют на ситуацию.

Также провёл аналогичный эксперимент, но уже с тяжёлым заданием (вместо вызова пустого метода через BC). Результаты те же. Линейное возрастание времени при последовательном увеличении числа запросов. Фактически отсутствие влияния параллельных запросов из двух источников.

[trud]

Т.е. что это значит? что кешировать ничего не нужно, оно и так работает?

[Sergey Petrov]

Цитата:

Сообщение от trud

Т.е. что это значит? что кешировать ничего не нужно, оно и так работает?

Видимо, да. По крайней мере, проведённые тесты говорят об этом.