Стресс-тестирование WCF на корпоративном сервере

Question

Я пишу, чтобы задать вопрос о производительности WCF.

1.Справочная информация

У нас есть система клиент-сервер, которая работает на .NET 3.5.Сервером является C # сервис , а клиентом - приложение silverlight .

Я написал стресс-тестер, который является приложением winforms и работает так:

• Он порождает рабочие процессы
• Работник обрабатывает различные стрессовые нагрузки [eg for (i=0;i<100;i++) Send(payload)]
• Служба работает как [ServiceBehavior(InstanceContextMode =InstanceContextMode.Single, ConcurrencyMode = ConcurrencyMode.Single)].
• Всетайм-ауты (операция, отправка, получение, ..) были установлены на максимум
• serviceThrottling: maxConcurrentSessions="200"
• Включена трассировка сообщений и печатается все

2,Проблема

После некоторых пороговых значений (в зависимости от нагрузочных нагрузок и тестируемой среды) мои рабочие процессы (обычные консольные приложения .NET 3.5 C #) начинают генерировать исключения.Сначала я получал timeoutExceptions, но после многих сеансов чтения и настройки я попал в точку, где я получаю только два исключения (только при очень высокой нагрузке)

• Базовое соединение было закрыто:Соединение, которое, как ожидали, будет поддерживаться в рабочем состоянии, было закрыто сервером.
• Произошла ошибка при получении ответа HTTP на.Это может быть связано с тем, что привязка конечной точки службы не использует протокол HTTP.Это также может быть связано с тем, что сервер прерывает контекст HTTP-запроса (возможно, из-за закрытия службы).См. Журналы сервера для более подробной информации.

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

3.Выполненные действия

Я прочитал много статей и настроил множество параметров (включая регулирование, тайм-ауты и т. Д.).Например, я попробовал все предложения здесь: http://www.codeproject.com/KB/WCF/WCFThrottling.aspx

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

В журналах трассировки вообще не сообщается об ошибках

4.В идеале ...

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

Возможно ли это в WCF через Http и однопоточный односторонний контекстный сервер?Я здесь пропускаю настройку или я получаю верхнюю границу и получаю ожидаемое поведение WCF?

Примечание: я пытался использовать ConcurrencyMode.Multiple.Я получаю улучшение (т. Е. Требуется больше нагрузки для достижения верхней границы), но я получаю те же исключения.

Answer 1

Полагаю, я "нашел" свой ответ!

Я объясню здесь, что я сделал на тот случай, если кто-то еще наткнется на него.

Прежде всего вы можете проверить счетчик Вызовы , который напоминает отставание T * CP *.

Кроме того, в perfmon может видеть, сколько вызовов обрабатывается одновременно и сколько в очереди.

Эти два показателя позволили мне подтвердить, что я действительно ударился о крышу. Поэтому мне нужен был код, который отправлял бы / rcv некоторые ACK при обмене сообщениями. К счастью, MS уже сделали это для нас! Это называется надежный обмен сообщениями WCF .

http://msdn.microsoft.com/en-us/library/ms730123.aspx http://msdn.microsoft.com/en-us/library/aa480191.aspx

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

Очевидно, что производительность снижается, но она действительно надежна.

Отлично, поэтому я думаю, что теперь, когда я нашел решение, я могу сказать пользователям, что все эти фантастические вещи есть, но они ничего не получат, потому что их клиент работает на Silverlight 3, который нет надежных реализаций WCF ... ууу!

Answer 2

Лучшим вариантом будет использование netMsmqBinding . Вот обзор того, как это работает, если вы не знакомы. Эта привязка позволит вашей службе поставить в очередь избыточную нагрузку с помощью MSMQ, чтобы сообщения не были потеряны. Это должно решить вашу проблему.

Answer 3

Вам также следует попробовать настроить конфигурацию ASP.NET Threapool: http://support.microsoft.com/kb/821268, поскольку служба размещена в IIS.

С уважением, Амит Бхатия

Answer 4

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

Предпочитайте использовать для каждого вызова или сеанса, если вам нужно поддерживать состояние для нескольких запросов.