Блог

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

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

У меня возникли проблемы с тем, как наилучшим образом определить состояние перегруженной сети. Если бы мне нужно было измерить время между отправкой запроса и началом ответа, это фактически дало бы мне время в оба конца. Если среднее значение этого времени значительно увеличивается, значит, у нас перегруженная сеть. Интересно, что «значительно» должно означать в этом случае.

Звучит ли это примерно так? Можете ли вы пролить больше света на эту проблему? Кто-нибудь там закодировал этот сценарий?

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

РЕДАКТИРОВАТЬ Чтобы уточнить, я говорю здесь о многих хостах и только об одном экземпляре приложения. У меня уже есть система, позволяющая избегать одновременных подключений к одному серверу (запросы доставляются из конца в конец), поэтому вопрос не столько в том, как насытить канал (я знаю, как это сделать), но как лучше ограничить запросы, чтобы избежать ошибок таймаута.

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

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

Обратите внимание, что в TCP уже есть алгоритмы контроля перегрузки, которые пытаются насытить канал даже для одного (1) соединения. Если загружаемые вами документы невелики (10 килобайт или более), вы, вероятно, обнаружите, что открытие множества подключений к одному и тому же серверу не ускорит процесс, а может замедлить его.

Единственный способ, которым поможет множество подключений к одному серверу, — это если (а) он сильно загружен, и ваша цель — просто использовать больше, чем ваша «справедливая доля» пропускной способности сервера; или (б) вы загружаете множество крошечных файлов по разным HTTP-соединениям, поэтому у алгоритма TCP недостаточно времени, чтобы адаптироваться к доступной пропускной способности канала.

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

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

Кто-то также предложил использовать прокси с ограничением пропускной способности.