Кто несет ответственность за подавление веб-запросов?

Я работаю над библиотекой классов, которая извлекает информацию со стороннего веб-сайта. Веб-сайт, к которому осуществляется доступ, перестанет отвечать на запросы, если в течение заданного периода времени (~0,5 секунды) будет сделано слишком много запросов.

Открытые методы моей библиотеки напрямую связаны с ресурсом-файлом на веб-сервере. Другими словами, каждый раз, когда вызывается метод, создается HttpWebRequest и отправляется на сервер. Если все идет хорошо, вызывающему объекту возвращается XML-файл. Однако, если это второй веб-запрос менее чем за 0,5 с, запрос будет таймаут.

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

Имеет ли смысл для моей библиотеки ставить в очередь и ограничивать веб-запросы, которые я создаю, или Моя библиотека должна просто выдавать исключение, если клиент не ждет достаточно долго между API звонки?

4 7
c# throttling httpwebrequest

4 ответа:

Концепция библиотеки заключается в том, чтобы дать своему клиентскому коду как можно меньше поводов для беспокойства. Поэтому я бы сделал это задачей библиотек, чтобы ставить запросы в очередь и своевременно возвращать результаты. В идеальном мире вы бы использовали модель обратного вызова или делегирования, чтобы клиентский код мог работать асинхронно, не блокируя пользовательский интерфейс. Вы также можете предложить возможность пропустить очередь (и потерпеть неудачу, если она работает слишком быстро) и, возможно, даже предложить приоритеты в модели очереди.

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

6

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

3

Это ответственность веб-сервера, ИМО. Поскольку критическая нагрузка зависит от оборудования, пропускной способности сети и т. д. Многие вещи, которые находятся вне контроля вашего приложения, он не должен беспокоиться о том, чтобы попытаться справиться с этим. IIS может регулировать трафик на основе различных параметров конфигурации.

2

Что это за клиент? Это интерактивный клиент, например: приложение на основе графического интерфейса?

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

1