Могут ли длительные HTTP-вызовы asyn c вызвать слишком много объектов во втором поколении сборки мусора?

Question

На записанном вебинаре по архитектуре обмена сообщениями докладчик упомянул некоторые проблемы с синхронными и длинными http / веб-запросами, когда G C продолжает ожидать объекты ответа и в конечном итоге перемещает их в поколение 2 G C. ,

Мне было бы любопытно, происходит ли то же самое с асинхронными c вызовами await также, поскольку речь идет не о потоках процессора, а скорее о утечке памяти.

static async Task Main(string[] args)
{

    string response = await LongHTTPRequest();
    Console.WriteLine(response);
}

public static async Task<string> LongHTTPRequest()
{
    await Task.Delay(12000);
    return await Task.FromResult("Response from RPC");
}

Answer 1

WebServers и Multitasking - странная комбинация:

1. С одной стороны, он интенсивно использует неявную многопоточность. Ваш средний ASP. NET Сервер имеет пул потоков размером от десятков до сотен потоков на ядро ​​процессора . А затем другой ThreadPool того же размера (но этот редко используется). На уровне запроса, это всеобъемлющий параллель .

2. С другой стороны, вам действительно следует избегать явного многозадачности на стороне сервера, если ты можешь. Весь дизайн предназначен для запросов:

   • получено
   • обработано
   • отправлено результатов
   • удалено из памяти как можно скорее, но не t ie увеличить ресурсы до

Если вы посмотрите на страницу Lifecycle for ASP Pages , вы можете ее увидеть. Но это в основном относится ко всем разработкам веб-страниц. И веб-сервисы. И Базы данных, для этого вопроса.

Явная многозадачность будет либо:

• слишком долго удерживать запрос в памяти, вызывая нехватку ресурсов (включая память, но меня больше беспокоит неуправляемость такие вещи, как соединения с БД здесь)
• не возвращаются вовремя для ответа, отбрасываются и, следовательно, тратят время и память процессора на то время, пока оно продолжается

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

Средняя веб-страница с изображениями уже является примером. Мы могли бы полностью отправить изображения встроенными , с остальной частью страницы. Мы знаем, как это сделать, с самого начала. Но мы редко делаем. Сервер отправляет чистую HTML страницу без встроенного изображения, но с большим количеством URL-адресов изображения. И тогда Браузер - клиент - будет асинхронно загружать каждое изображение, файл CSS и фрагмент кода JavaScript (два последних, скорее всего, будут встроены, но также не гарантируют). Один отдельный запрос за раз.