Соединитель SAP .NET занимает много времени для получения результатов с первой попытки

Question

У меня проблема с соединителем SAP .NET

Я создал веб-приложение (ASP.NET, C#), которое подключается к процедуре SAP BAPI для получения результатов из базы данных SAP.

Я подключил его к процедуре SAP BAPI, и он также получает результаты для веб-приложения.

Моя проблема в том, что во время первой попытки получение результатов занимает от 25 до 30 секунд, но со второй попытки результаты извлекаются без времени.

Я не знаю точно, почему получение результатов с первой попытки занимает так много времени.

Может ли кто-нибудь помочь мне с этим?

Answer 1

Прошло много времени с тех пор, как этот был открыт, но его можно решить (это даже довольно легко, если вы знаете, что делать).

У нас была та же проблема: задержка более 10 секунд до установления соединения. В транзакции SM21 целевых серверов соединение не было видно, пока клиент не получил ответ.

Я запечатлел трассировку сети и увидел, что это действительно шлюз, проходящий время между запросом и ответом. В файле журнала серверов dev_rd (журнал отладки шлюза) появилась (после начальной задержки) довольно очевидная запись:

Fri Aug  3 07:55:20:963 2018
NiHLGetHostName: to get [private-ip] failed in 12004ms (tl=2000ms; MT; UC)
*** ERROR => NiHLGetHostName: NiPGetHostByAddr failed (rc=-1) [nixxhl.cpp   514]

Попытка получить ответ DNS для этого IP также не удалась с помощью инструмента nslookup. Следующие запросы выполняются намного быстрее, поскольку шлюз, по-видимому, кэширует отрицательные попадания, но как только время входа истечет, вы снова столкнетесь с задержкой.

Следовательно:

1. Сконфигурируйте свой DNS-сервер (добавьте частные зоны с помощью in-addr.arpa для успешного обратного просмотра), чтобы шлюзу не приходилось время ожидания.

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

2. следуйте примечанию 1055602, чтобы окончательно деактивировать обратный поиск с помощью параметра rdisp/reverse_name_lookup.

Answer 2

Я также вижу эту задержку, и именно в этот момент мы используем соединитель для установления соединения с SAP, а не что-либо связанное с SQL.

Я предполагаю, что это потому, что с первой попытки соединитель должен установить соединение, аутентифицировать и инициализировать свой пул соединений.

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

Ваш лучший способ действий - просто один раз установить соединение и затем использовать его как можно чаще.

Answer 3

Это обычное поведение, которое в действительности вызвано тем, что SAP NCo впервые получает метаданные для BAPI.

Получив метаданные, он кэширует их для последующих вызовов, которые должны быть быстрыми.

Я регулярно вижу время первого вызова BAPI_PO_CREATE1 ~10 секунд, последующие вызовы ~ 1 секунда.

Answer 4

Я наблюдал аналогичное поведение, что означает проблему с производительностью при использовании систем SAP S/4HANA 2022, которые были развернуты через библиотеку SAP Cloud Appliance с использованием общедоступных IP-адресов. В нашем случае первоначальный вход в систему с использованием инструментов разработки ABAP (ADT) на базе Eclipse был очень медленным, в то время как последующие запросы выполнялись быстро. Оказалось, что платформа попыталась разрешить внутренний IP-адрес клиента, но при первом вызове это не удалось. Последующие вызовы были быстрыми, поскольку IP-адреса (в данном случае это означает те, которые не удалось) были кэшированы. В результате при последующем вызове платформа не пытается разрешить эти IP-адреса во второй раз. В более новых версиях, чем те, которые указаны в вышеупомянутом примечании, можно установить второй параметр, специфичный для службы шлюза SAP (не путать с шлюзом SAP).rdisp/reverse_name_lookupgw/resolve_phys_addr Оба могут быть установлены в 0. И это также работает с использованием транзакции RZ11 временно, пока сервер приложений не перезапускается. Оба параметра я установил на 0.