Число сессий в веб-сервисе на AIF

[Dark Light]

AX2012R3

Создан веб-сервис через AIF. Выделен отдельный АОС, который обрабатывает запросы веб-сервиса. Клиентов больше 100, но все они вызывают его под одним и тем же пользователем АХ.

Проблема в том, что на каком-то этапе время отклика веб-сервиса становится очень долгим. Даже самый примитивный метод срабатывает спустя полминуты. При этом:
- Нет проблем с памятью или ЦП.
- Нет проблем с БД.
- Число сессий выделенного пользователя на АОСе всегда равно 10.
- В настройках адаптера (binding) максимальное число сессий равно 200.

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

[Logger]

Может просто блокировки идут.
Например при логине идет попытка синхронизации или пересоздания хранимки. Посмотрите какие запросы при этом в базу идут.

[Dark Light]

Есть другой АОС, Когда запросы одного-двух клиентов перенаправляются туда, то для них всё работает мгновенно. БД, понятно, используется одна и та же.

[Logger]

Загрузку проца еще проверьте.
Иногда бывает бага когда сессия выжирает все процессорное время и из-за этого логин других сессий идет крайне медленно. Даже по RDP на сервак не войдешь нормально.

[Dark Light]

Загрузка ЦП не превышает 10%. А обычно трется около 1%.

[gl00mie]

Цитата:

Сообщение от Dark Light

При этом:
- Число сессий выделенного пользователя на АОСе всегда равно 10.
- В настройках адаптера (binding) максимальное число сессий равно 200.

Максимальное число сессий - это, наверно, MaxConnections (вообще, в подобных случаях очень помогает кусок WCF-конфигурации сервиса AIF). Посмотрите на параметры WCF для управления производительностью и масштабируемостью, например, MaxConcurrentSessions по умолчанию как раз равно 10.

[Dark Light]

Проблема разрешилась.

Все ограничения на сессии стояли на уровне 200 штук. И этот лимит был превышен, т.к. подключения к веб-сервису принудительно не закрывались (теперь закрываются). Т.о. новым подключениям приходилось ждать, когда "отомрут" старые. При этом, это именно сессии подключения к веб-сервису и они никак не связаны с сессиями АХ (которых было 10). Поэтому причину удалось обнаружить только через netstat.

Спасибо всем за помощь )

[Logger]

А почему они не закрывались ?
Что было не так ?

[gl00mie]

Ну как, это ж типа оптимизация: вдруг клиент еще что-нить спросить захочет, придется заново соединение устанавливать, аутентифицироваться, все дела, а тут - готовое соединение висит "на низком старте".

[Logger]

Так обычно таймаут есть неравный бесконечности.
Или он был слишком большой.

[Dark Light]

Цитата:

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

А почему они не закрывались ?
Что было не так ?

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

Цитата:

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

Так обычно таймаут есть неравный бесконечности.
Или он был слишком большой.

Да, был довольно большой. А частота запросов была очень высокой - не успевали закрываться по таймауту. Поэтому и на тестировании эта проблема не всплыла - было мало запросов.

[Alex_KD]

Была такая же проблема. Насколько я помню, парамеры Throttling на это тоже влияют.