Регулирование WCF и ограничения подключений

Я просмотрел Интернет и переполнение стека в поисках ответов, но, похоже, я не могу получить четкого ответа на свои проблемы.

У меня около 50 клиентов по всей стране, которые регулярно открывают вызов WCF WSHTTPBinding автоматически через службу Windows на сервер каждые 10-20 минут. Это хорошо работает, потому что я ограничиваю количество клиентов, которые могут подключаться и выполнять длительные операции через сервер, а затем клиент знает, что он ничего не может сделать, и пытается в следующий раз выполнить повторную проверку.

Это работало хорошо до вчерашнего дня, когда у одного клиента, у которого есть 7 отдельных систем за одним и тем же маршрутизатором, начались очень-очень медленные проблемы с Интернетом. Таким образом, эти 7 систем будут открывать соединение с сервером каждые 10-20 минут и выполнять свои процедуры «регистрации». Вызовы займут некоторое время, и каждая система может быть подключена к службе одновременно, используя до 7 подключений к серверу. Остальные 43 системы также должны проходить регистрацию каждые 10-20 минут. Но поскольку у клиента с 7 системами был медленный Интернет, вызовы длительных процессов в сервисе занимали больше времени, чем обычно, и, в конечном итоге, отключались на клиенте (иногда я даже получал устаревшие ошибки меток времени безопасности). В свою очередь, это могло иногда приводить к зависанию службы WCF от ответа на любые другие клиентские запросы, а затем, в конечном итоге, время ожидания клиента истекало, и серверные соединения очищались и обрабатывали другие запросы.

Мне нужно, чтобы на мою службу не влияли проблемы с Интернетом клиентов, и служба должна продолжать работать, обслуживая других клиентов, которые продолжают «регистрироваться».

Теперь я уже реализовал поведение регулирования службы на стороне службы:

Dim stb As New ServiceThrottlingBehavior
stb.MaxConcurrentSessions = 100
stb.MaxConcurrentCalls = 20
stb.MaxConcurrentInstances = 120

serviceHost.Description.Behaviors.Add(stb)

Я кое-что почитал и нашел этот параметр, но на данный момент в моем коде его нет:

System.Net.ServicePointManager.DefaultConnectionLimit

Который я пытался понять, но не понял полностью. Итак, теперь с моим объяснением, вот мои вопросы:

  • Do I set System.Net.ServicePointManager.DefaultConnectionLimit at the service or client end?
  • Where would I set that? Before I open the ServiceHost? Before I create the ServiceHost?
  • Are there any other areas to change for connection limits and concurrent calls for WCF? (It seems from my reading there can be a few, depending on what binding you're using)

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

Спасибо.


person ScottN    schedule 11.02.2011    source источник


Ответы (1)


Я не понимаю, что делает ваш сервис, что "медленный интернет" должен на него повлиять. Вы отправляете огромные объемы данных туда и обратно при каждой регистрации? Без более подробной информации о дизайне трудно сказать, что происходит.

Тем не менее, я думаю, вам стоит еще раз взглянуть на дизайн. Если сервер выполняет действительно длительную операцию, прежде чем он сможет ответить клиенту, клиент не должен просто оставаться и ждать его по HTTP в течение 10 минут за раз. Было бы разумнее отправить запрос, а затем либо проверять время от времени, чтобы убедиться, что он выполнен (и не требуется ли удерживать соединение), либо использовать net.tcp в качестве привязки и использовать что-то, что больше подходит для удержания таких длительных подключений ( net.tcp также может использовать обратный вызов для уведомления клиента о завершении вызова).

person Tridus    schedule 11.02.2011
comment
Да, большие объемы данных передаются на сервер от клиента, поэтому есть загрузка данных из интернет-соединения, которое, если оно медленное, будет поддерживать соединение открытым и, в конечном итоге, приведет к тайм-ауту. Итак, дизайн есть и работает, это проблема с лимитом подключения. Какая часть моих вопросов касается DefaultConnectionLimit и как его реализовать. - person ScottN; 12.02.2011
comment
Если вы отправляете много данных, использование потоковой передачи может работать лучше. По моему опыту, IIS обрабатывает их, так что до WCF он даже не попадет, пока данные не будут переданы в потоковом режиме. - person Tridus; 12.02.2011
comment
Я согласен, я мог бы повторно посетить дизайн, но для немедленного решения проблемы клиентов, задерживающих соединение, потому что он медленно загружает данные на сервер, я хотел бы знать, как реализовать большую гибкость на сервере, чтобы принимать больше подключений одновременно. Судя по тому, что я читал, 10 - это предел. Таким образом, если 6–7 используют соединения, от других 43–44 клиентов не потребуется намного больше, чтобы достичь этого максимального ограничения на количество подключений. - person ScottN; 12.02.2011
comment
10 - это предел сеанса, но вы его увеличиваете. В соответствии с этим вы можете попробовать полностью отключить сеансы, чтобы обойти это ограничение: dotnetconsult.co.uk/weblog2/ - person Tridus; 12.02.2011
comment
Я думаю о внедрении NetTCPBinding и постепенном переводе клиентов на это. Кажется, может быть какое-то ограничение wsHTTPBinding, которое нельзя изменить ... по крайней мере, насколько я понимаю. Что ты думаешь? stackoverflow.com/questions/832871/ - person ScottN; 14.02.2011
comment
У меня нет конкретного ответа, потому что у меня нет большого опыта работы с wsHttpBinding. Я стараюсь избегать этого, потому что это настолько сложно, что многие странные вещи могут пойти не так. Я думаю, что в зависимости от продолжительности выполняемых вами операций, net.tcp будет лучшим связыванием, поскольку он предназначен для расширенных или постоянно действующих соединений. Вероятно, это тоже будет быстрее! - person Tridus; 14.02.2011