AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Программирование
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 16.09.2020, 14:09   #1  
Sergey Petrov is offline
Sergey Petrov
Участник
 
80 / 19 (1) ++
Регистрация: 03.04.2007
Адрес: Saint-Petersburg, Russia
Business Connector и его сессии
Коллеги, добрый день!

Есть вопрос по практическому использованию 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.

Поделитесь опытом, пожалуйста.
__________________
MS Dynamics AX 2009

Kernel 5.0.1600.4110
Application 5.0.1500.6491
Старый 16.09.2020, 14:27   #2  
Weez is offline
Weez
Участник
Axapta Retail User
 
250 / 84 (3) ++++
Регистрация: 18.01.2006
Адрес: Moscow city
Добрый день, использую Business connector в той же конфигурации, что вы описали. Написали свой вебсервис, при обращении к которому через сессию бизнес-коннектора вызывается статик метод с параметрами в аксапте. Никакой проблемы с производительностью не замечал, правда обратил внимание что сейчас существует открытая сессия бизнес-коннектора в активных пользователях, хотя запрос выполнялся довольно давно. Можно, скорее всего, принудительно закрывать сессию - но смысла особого не вижу, и так работает стабильно.
__________________
Существует 10 типов людей: одни понимают двоичную систему, другие - нет.
Старый 16.09.2020, 17:42   #3  
_scorp_ is offline
_scorp_
Участник
Аватар для _scorp_
MCBMSS
 
488 / 369 (13) ++++++
Регистрация: 25.07.2007
Адрес: Москва
Добрый день.

С точки зрения производительности мы пришли к следующему решению: Есть web-сервис, к которому могут обращаться внешние приложения. У web-сервиса есть пул бизнес коннекторов с открытым подключением (размер пула прописываем в web.config). Если в web-сервис приходит какой-то запрос - смотрим в пул - есть там свободный BC или нет, если есть, то запрос его забирает, выполняет с ним обращение к AX и возвращает в пул (пул его принимает если размер пула не максимальный). Если в пуле свободного BC нет - создается новый BC => устанавливается соединение к AX => вызывается какая-то логика в AX => попытка положить BC в пул. Если в пуле максимальное число доступных BC - закрываем соединение с AX. Если пул не полный - не закрываем соединение для BC и кладём его в пул. Несколько раз в день на периодической основе пул "рефрешим" (на всякий случаем переоткрываем соединения для BC в пуле).
За это сообщение автора поблагодарили: Logger (3).
Старый 16.09.2020, 19:05   #4  
Raven Melancholic is offline
Raven Melancholic
Участник
Аватар для Raven Melancholic
Самостоятельные клиенты AX
Лучший по профессии 2015
 
2,158 / 1286 (47) ++++++++
Регистрация: 21.03.2005
Адрес: Москва-Петушки
Цитата:
Сообщение от 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 запросов, но они уже сто раз обсуждены на специализированных форумах.

Последний раз редактировалось Raven Melancholic; 16.09.2020 в 19:09.
За это сообщение автора поблагодарили: Logger (3), Sergey Petrov (1).
Старый 17.09.2020, 01:53   #5  
trud is offline
trud
Участник
Лучший по профессии 2017
 
1,038 / 1629 (57) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Цитата:
Сообщение от Raven Melancholic Посмотреть сообщение
А вот если запросов много, компания одна, то постоянное соединение может дать выигрыш.

То есть, есть какой-то пул открытых соединений, при обращении за бизнес-логикой вызывается не Axapta.LogonAs, а запрашивается соединение из пула, а уже пул решает есть ли у него свободные соединения, можно ли отдать такое соединение или нужно создать новое, сам пул обслуживает открытые соединения и если они долго не используются закрывает их, определяет «зависшие» соединения и т. п.
Кстати интерестно - а вы тестировали подобный подход(что пул будет давать какой-то выигрыш) или это просто размышления? Мне казалось что АОС уже сам делает что-то подобное, хотя возможно зависит от версии. Ну и надо тестировать конечно же
Старый 17.09.2020, 12:30   #6  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,867 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Цитата:
Сообщение от trud Посмотреть сообщение
Кстати интерестно - а вы тестировали подобный подход(что пул будет давать какой-то выигрыш) или это просто размышления? Мне казалось что АОС уже сам делает что-то подобное, хотя возможно зависит от версии. Ну и надо тестировать конечно же
Com коннектор в 2009-й точно не делает. Я проверял.
Возможно ли кешировать COM соединения в PHP ?
там периодически подвисания идут при логине на весьма прогретом сервере под нагрузкой.

.Net не замерял, но сомневаюсь что делает.
За это сообщение автора поблагодарили: trud (2).
Старый 17.09.2020, 18:46   #7  
Raven Melancholic is offline
Raven Melancholic
Участник
Аватар для Raven Melancholic
Самостоятельные клиенты AX
Лучший по профессии 2015
 
2,158 / 1286 (47) ++++++++
Регистрация: 21.03.2005
Адрес: Москва-Петушки
Особо сверхточных измерений с использованием каких-то инструментов не делал. Реализация была для DAX2009 из внешней WEB службы на C#, работающей на IIS. Для DAX4 это была Windows служба, так же написанная на C#.
Было просто:
1. С службе перед входом в цепочку писался лог.
2. В DAX в начале статического метода писалось в свой лог.
3. В DAX в конце метода писалось в свой лог.
4. В службе после окончания цепочки писался лог.
Потом в Excel компоновал эти логи. Смотрел на время между 1-2 и 3-4.
Конкретные цифры не помню, логов этих не сохранилось В целом сокращение при использовании пула было суммарно в районе секунд. Что интересно, что сокращение для 3-4 было больше, чем для 1-2, то есть, получалось что отключение более тормозное, чем коннект.
Ну, главное, что пользователи стали меньше жаловаться на подвисания.
Тут еще есть особенность - сама работа в DAX была короткой, оптимизировано там было здорово, специально вместо длинной операции делались несколько коротких, поэтому разница визуально была заметна. Понятно, что если сама обработка в DAX будет долгой, то наверное выигрыш не будет стоить усложнения.
Старый 17.09.2020, 19:13   #8  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,867 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
А в моем случае было так.
Был сканер на складе, который на каждом пике в php создавал com объект аксапты, делал коннект и получал / отправлял какие-то данные. Со стороны юзеров было требование, что длина пика не должна превышать 1 сек. Реально на прогретом приложении все укладывалось в 100-200 миллисекунд. Но периодически были выбросы до нескольких секунд и иногда довольно частые. Юзеров это сильно нервировало.

Делали трассировку, в которой было видно что выполнялась вся цепочка вызовов как при обычном интерактивном входе в аксапту и в неожиданных местах, например на вызове метода класса WinApiServer, шло подвисание. Похоже была конкуренция за какой-то ресурс. Или в .net неудачно мусор в этот момент собирался или еще что-то. В любом случае накладные расходы по логину в аксапту явно смотрелись лишними.
Старый 21.09.2020, 13:35   #9  
Sergey Petrov is offline
Sergey Petrov
Участник
 
80 / 19 (1) ++
Регистрация: 03.04.2007
Адрес: Saint-Petersburg, Russia
Коллеги, провёл эксперимент - вызывал пустой тестовый метод заданное количество раз подряд. Второй эксперимент - из двух браузеров параллельно запускал вызов того же самого тестового пустого метода, чтобы посмотреть на внутреннюю конкуренцию при параллельных коннектах.
Вывод - время выполнения задания увеличивается практически линейно с увеличением количества повторов (100 - около 3 секунд, 1000 - за 35 секунд). То есть, на одно подключение - порядка 0,03 секунды, нет задержек, связанных с накоплением ожидания каких-то ресурсов. При параллельном выполнении задания из двух браузеров результаты остались неизменны. То есть, параллельные подключения и отключения также не влияют на ситуацию.

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

Kernel 5.0.1600.4110
Application 5.0.1500.6491
За это сообщение автора поблагодарили: trud (2).
Старый 21.09.2020, 13:40   #10  
trud is offline
trud
Участник
Лучший по профессии 2017
 
1,038 / 1629 (57) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Т.е. что это значит? что кешировать ничего не нужно, оно и так работает?
Старый 21.09.2020, 13:44   #11  
Sergey Petrov is offline
Sergey Petrov
Участник
 
80 / 19 (1) ++
Регистрация: 03.04.2007
Адрес: Saint-Petersburg, Russia
Цитата:
Сообщение от trud Посмотреть сообщение
Т.е. что это значит? что кешировать ничего не нужно, оно и так работает?
Видимо, да. По крайней мере, проведённые тесты говорят об этом.
__________________
MS Dynamics AX 2009

Kernel 5.0.1600.4110
Application 5.0.1500.6491
Теги
businessconnector

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
The right cloud option for your business sukhanchik DAX Blogs 6 26.02.2017 17:26
atinkerersnotebook: Creating Lifecycle Services Business Process Models Blog bot DAX Blogs 0 09.04.2014 15:11
Inside Dynamics AX 4.0: Working with the .NET Business Connector Blog bot DAX Blogs 0 04.10.2007 05:15
Inside Dynamics AX 4.0: Inside the Business Connector Blog bot DAX Blogs 0 04.10.2007 05:15
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 20:33.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.