Durante o Techdays aqui na Holanda, Steve Sanderson fez uma apresentação sobre C # 5, ASP.NET MVC 4 e Web assíncrona.

Ele explicou que, quando as solicitações levam muito tempo para serem concluídas, todos os threads do pool de threads ficam ocupados e as novas solicitações precisam esperar. O servidor não pode lidar com a carga e tudo fica mais lent

m seguida, o @ mostrou como o uso de solicitações da Web assíncronas melhora o desempenho, porque o trabalho é delegado a outro encadeamento e o conjunto de encadeamentos pode responder rapidamente a novas solicitações recebidas. Ele até demonstrou isso e mostrou que 50 solicitações simultâneas usavam 50 * 1s, mas com o comportamento assíncrono em vigor, apenas 1,2 s no tota

Mas depois de ver isso, ainda tenho algumas pergunta

Por que não podemos simplesmente usar um threadpool maior? Não está usando async / waitit para abrir outro thread mais devagar do que apenas aumentando o pool de threads desde o início? Não é como se o servidor em que rodássemos de repente tivesse mais threads ou algo assim?

A solicitação do usuário ainda está aguardando a conclusão do encadeamento assíncrono. Se o thread do pool está fazendo outra coisa, como o thread da 'UI' é mantido ocupado? Steve mencionou algo sobre 'um kernel inteligente que sabe quando algo termina'. Como é que isso funciona