Масштабирование нескольких запросов HttpWebRequests?

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

Я действительно устанавливаю ServicePoint ConnectionLimit в app.config, чтобы это не было ограничивающим фактором.

Мне нужно резко увеличить масштаб. По крайней мере, мне понадобится немного больше мощности процессора, но мне интересно, получу ли я какие-либо преимущества, используя асинхронные методы объекта HttpWebRequest (например: .BeginGetResponse ()), в отличие от самостоятельного создания потоков и использования синхронные методы (например: .GetResponse ()) в этих потоках.

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

Спасибо!


c# httpwebrequest scalability
person Redth    schedule 12.07.2010    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Если вы работаете в Windows NT, то класс System.Net.Sockets.Socket всегда использует порты завершения ввода-вывода для асинхронных операций. А HTTPWebRequest в асинхронном режиме использует асинхронные сокеты и, следовательно, будет использовать IOCP.

Без подробного тестирования трудно сказать, находится ли наше узкое место внутри HttpWebRequest, вверх по стеку, в вашем приложении или на удаленной стороне, на сервере. Но сразу, несомненно, asyncc даст вам лучшую производительность, потому что в конечном итоге он будет использовать IOCP под прикрытием. И повторно реализовать приложение для асинхронной обработки не так уж и сложно.

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

person feroze    schedule 25.07.2010

arrow_upward
0
arrow_downward

Самый быстрый результат для меня - использование 75 потоков, выполняющих синхронизацию httpwebrequest. Около 140 запросов в секунду на сервере Windows 2003, 4 ядра 3 ГГц, соединение 100 МБ.

Асинхронный Httprequest / winsock зависал примерно на 30-50 запросах в секунду. Не тестировал синхронизацию winsock, но я думаю, это даст вам примерно тот же результат, что и httpwebrequest.

Тесты прошли против 1 200 000 блогов.

В последний месяц боролись с этим, поэтому было бы интересно узнать, удалось ли кому-то выжать из .net больше?

РЕДАКТИРОВАТЬ

Новый тест: Получено 350 запросов / сек с iocp-компонентом xfserver. Использовал кучу потоков с одним экземпляром в каждом перед достижением какого-либо большего результата. В «клиентской части» библиотеки было несколько досадных ошибок, которые усложняли реализацию, чем «серверная часть». Не то, что вы просите и не рекомендуется, а какой-то шаг.

Далее: в предыдущем тесте winsock не использовался SocketAsyncEventArgs 3.5, который будет следующим.

ОТВЕТ

Ответ на ваш вопрос, нет, не стоит затраченных усилий. Асинхронные методы HttpWebRequest разгружают основной поток, сохраняя загрузку в фоновом режиме, это не улучшает количество / масштабируемость запросов. (по крайней мере, не в 3.5, может быть иначе в 4.0?)

Однако, возможно, стоит обратить внимание на создание собственной оболочки вокруг асинхронных сокетов / SocketAsyncEventArgs, где работает iocp, и, возможно, реализовать шаблон начала / конца, аналогичный HttpWebRequest (для простейшей реализации в текущем коде). Улучшение действительно огромно.

person Simon    schedule 13.07.2010
comment
У меня создалось впечатление, что Async HttpWebRequests должен использовать порты завершения ввода-вывода, которые, как я думал, отличаются от ThreadPool по умолчанию ... Теперь я немного смущен, поскольку я ожидал, что это будет намного быстрее, чем синхронные веб-запросы на кучу потоки... - person Redth; 14.07.2010
comment
Да, должен, но пока я еще не видел ни одного рабочего примера клиента, который получает более 50 одновременных запросов. В моем случае я анализирую первые байты, чтобы убедиться, что это действительно xml-канал, я предполагаю, что любой синтаксический анализ / результат все равно будет выполняться в объединенном рабочем потоке. Я могу ошибаться, но я предполагаю, что асинхронные запросы .net в основном нацелены на фоновые загрузки без блокировки потока пользовательского интерфейса в приложениях с графическим интерфейсом, а не для запуска как можно большего количества одновременных запросов. - person Simon; 15.07.2010