2009-02-05 4 views
2

У меня есть спам в веб-сервисе. Мой (веб-сервис) находится в gsoap & управляемый C++. Это не IIS/apache, но говорит xml. Мой клиент находится в .NET Время вычисления услуги светлое (< 0.1s для подготовки ответа). Я ожидаю, что сервис будет плавным, быстрым и будет иметь хорошую доступность. У меня около 100 клиентов, время ответа 1 обязательное. У клиентов около 1 запроса в минуту. Клиенты проверяют присутствие веб-сервисов с помощью теста tcp open port. Итак, чтобы избежать возможных перегрузок, я превратил gSoap KeepAlive в false. Пока все не работает нормально: я не вижу связи в TCPView (sysinternals)Ухудшение веб-сервиса

Новая специальная программа синхронизации теперь вызывает службу в цикле. Это более высокая нагрузка, но все обрабатывается менее, чем за 30 секунд. С sysinternals TCPView, я вижу, что около 1 000 подключений находятся в TIME_WAIT. Они замедляют обслуживание, и теперь требуется секунд, чтобы служба ответила.

Может быть, мне нужно сбросить соединение SoapHttpClientProtocol? У кого-то есть призраки TIME_WAIT с вызовом веб-службы в цикле?

ответ

1

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

+0

Я согласен. Я хочу, чтобы KeepAlive = false на стороне сервера, но на стороне клиента, .NET, похоже, предпочитает переработку по умолчанию. Я нашел это решение: http://yakkowarner.blogspot.com/2008/11/calling-web-service-in-loop.html Но он выглядит тяжелым. Я пытаюсь сделать это: http://forums.asp.net/t/1003135.aspx – wiwulo

0

Будьте очень осторожны с описанными выше реализациями. С ними серьезные проблемы.

  1. Реализация описанной в yakkowarner.blogspot.com/2008/11/calling-web-service-in-loop.html (К.П ВЫШЕ):

    ПРОБЛЕМА: Вся ваша работа будет быть уничтоженным при следующем восстановлении веб-службы с помощью wsdl.exe, и вы забудете, что не заметили, что это исправление довольно хаки, полагаясь на строку сообщения, чтобы принять меры.

  2. Реализация описанной в forums.asp.net/t/1003135.aspx (COMMENT ВЫШЕ):

    ПРОБЛЕМА: Вы выбираете конечную точку между 5000 и 65535, так на поверхности это выглядит как хорошая идея. Если вы думаете об этом, нет способа (по крайней мере, я не могу думать), что вы можете зарезервировать порты, которые будут использоваться позже. Как вы можете гарантировать, что следующий порт в вашем списке в настоящее время не используется? Вы последовательно выбираете порты для использования, и если какое-либо другое приложение выбирает порт, следующий в вашем списке, тогда вы будете закрыты. Или что, если какое-либо другое приложение, запущенное на вашей клиентской машине, начнет использовать случайные порты для своих соединений - вы будете входить в неотложные моменты времени. Вы бы СЛУЧАЙНО получили сообщение об ошибке, такое как «удаленный хост не может быть достигнут или недоступен» - еще труднее устранить неполадки.

Хотя я не могу дать вам правильное решение этой проблемы, некоторые вещи, которые вы можете сделать это:

  1. Попытка свести к минимуму число запросов веб-служб или распространять их больше больше более длинный период времени
  2. Для вашего типа приложения, возможно, веб-службы были неправильной архитектурой - для чего-то с 1 мс временем ответа вы должны использовать систему обмена сообщениями, а не веб-службу.
  3. Позволяет установить количество подключенных к вашей ОС подключений до 65K, используя реестр, как в Окна
  4. Установить вам время ОС, что сокеты остаются в TIME_WAIT к некоторому меньшему числу (это представляет свой собственный список проблем)