WCF - WebHttpBinding - RESTful - Performance Issue

Question

первый раз постер так легко на меня.

В настоящее время я пытаюсь решить проблему производительности при попадании на мой веб-сервис после одного минута бездействия. Буквально спустя минуту после того, как пользователь THAT не попадет в веб-службу, следующий вызов займет 15 секунд, прежде чем на самом деле удастся выполнить операцию. Если вы продолжаете делать случайные (не то же самое действие службы, что и вы, ребята, не думаете, что это «кеширование» вызова), операция службы вызывает немедленное возвращение службы (менее секунды).

Вот некоторые «тайминги» я решил взять, чтобы вы могли видеть, как я пришел в одну минуту бездействия:

1. 2:04 PM
2. 2:16 вечера --15 секунд
3. 2:21 PM --15 секунд
4. 2:24 PM --15 секунд
5. 2:25 вечера --15 секунд

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

Вот некоторые подробности, касающиеся моего веб-сервиса:

1. WCF, WebHttpBinding, RESTful, используя HTTPs.
2. Основная аутентификация + пользовательская аутентификация с использованием IDispatchMessageInspector. Аутентификация происходит при каждом вызове (кроме страницы Initializer.aspx).
3. Создана пользовательская страница Initialization.aspx, которая вызывается каждую ночь после повторного использования пула приложений. На этой странице хранится куча глобальных данных, используемых всеми пользователями, а также запуск этой компиляции.
4. Приложение Pool ТОЛЬКО перерабатывает каждую ночь в 2 часа ночи. Рабочие потоки никогда не уничтожаются, поскольку тайм-аут отключен.

Я слышал о ReliableSession, но поскольку установка предполагает, что звучит так, это будет работать только для PerSession, а не PerCall.

Есть ли способ разрешить это или я придерживаюсь прибегать к «pinging» серверу каждые 45 секунд, используя операцию фиктивного обслуживания?

Answer 1

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

Таким образом, в принципе, он не сможет связаться с контроллерами домена N +, пока он не достигнет единственного возможного.

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