StreamReader ReadToEnd() после HttpWebRequest EndGetResponse() — самый масштабируемый?

Я вызываю веб-службу RESTful в серверной части некоторых страниц ASP.NET.

Я использую асинхронные страницы ASP.NET, поэтому внутри я использую методы:

HttpWebRequest BeginGetResponse()

и

HttpWebRequest EndGetResponse()

Строка ответа в моем случае всегда представляет собой строку JSON. Я использую следующий код для чтения всей строки:

using (StreamReader sr = new StreamReader(myHttpWebResponse.GetResponseStream()))
{
  myObject.JSONData = sr.ReadToEnd();
}

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

Спасибо, Фрэнк


rest asp.net httpwebrequest streamreader
person frankadelic    schedule 18.01.2010    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Это зависит от того, что вы подразумеваете под «масштабируемостью». Если вы говорите о возможности обрабатывать все большие и большие файлы, я бы сказал, что это не очень масштабируемо. Поскольку вы используете один ReadToEnd, огромный поток потребует, чтобы весь поток был прочитан в память, а затем обработан. По мере роста количества, сложности и размера потоков приложений вы обнаружите, что это начнет снижать производительность сервера при обработке запросов. Вы также можете обнаружить, что ваш пул приложений начнет перерабатывать себя ВО ВРЕМЯ вашего запроса (если вы в конечном итоге займете столько виртуальной памяти).

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

person Joel Etherton    schedule 18.01.2010
comment
Обработка больших файлов не является проблемой — ответы JSON обычно находятся в диапазоне от 1 до 10 килобайт. Я имею в виду масштабируемость в том смысле, что она может обрабатывать множество одновременных запросов. - person frankadelic; 19.01.2010
comment
Я бы сказал, что ваши потоки должны быть независимыми от какого-либо кода распределения ресурсов — в основном любого вторичного потока или объекта соединения, и он должен масштабироваться вместе с вашим пулом приложений. Это сведется к возможностям ЦП/памяти/сети. Сохранение кода с правильной областью действия (как в вашем мини-примере) должно позволить огромное количество одновременных подключений асинхронно. - person Joel Etherton; 19.01.2010
comment
Вы делаете HTTP-запрос к тому же внутреннему серверу из своего приложения ASPX? Если это так, вам нужно будет увеличить максимальное количество подключений в настройках WebRequest. В противном случае, даже если ваш сервер IIS обслуживает огромное количество клиентов, страницы будут регулироваться количеством исходящих подключений, доступных для HTTPWebRequest. Вы можете установить ограничение следующим образом: ServicePointManager.DefaultConnectionLimit = 100; // например; - person feroze; 23.01.2010
comment
@feroze - в этом случае я звоню на сторонний внутренний сервер. Есть ли недостаток в установке очень высокого значения DefaultConnectionLimit? - person frankadelic; 26.01.2010