O IIS W3WP usa E / S sem bloqueio para fornecer conteúdo estático?

4

Digamos que ...

O IIS está atendendo a um recurso .MP3 estático com 10 MB de tamanho. A solicitação para o recurso vem para o HTTP.sys e é enviada para o processo W3WP apropriado para manipular. O processo de trabalho, em seguida, pega um thread do pool para processar essa solicitação. Agora, do meu pressuposto, o encadeamento será E / S enquanto lê o recurso .MP3 do disco. Isso é exato? Cada vez que uma solicitação chega para este item, um thread do pool está lendo o mesmo conteúdo do disco? O W3WP usa E / S sem bloqueio para obter o item?

Em seguida, digamos que há 1000 solicitações simultâneas para o mesmo arquivo .MP3; por causa do tamanho comparado a outros recursos solicitados, isso pode causar impactos no site? Lentidão, filas, etc?

    
por sinclairchase 09.12.2014 / 23:38

1 resposta

3

Depende de como você escreve seu serviço ou aplicativo da web. E é importante que concordemos com o que "não-bloqueio" ou "assíncrono" significa neste contexto.

Geralmente, não, o w3wp.exe não usa chamadas de E / S assíncronas ao recuperar arquivos do armazenamento para servir conteúdo estático. Mas é claro que isso não significa que o w3wp.exe esteja completamente inoperante porque ele está servindo um arquivo de 10MB no momento. Cada processo de trabalho (do qual pode haver várias instâncias simultâneas em execução em um servidor) cada um possui um conjunto de encadeamentos inteiro, incluindo encadeamentos dedicados para operações de E / S, à sua disposição.

QuandoumusuáriosolicitaumarquivoestáticodoIISpelaWeb,ow3wp.exeemiteumaIRP_MJ_CREATE(APICreateFile)paraoarquivosolicitado.(Issopodevirdeumdiscorígido,oupodevirdeumcachedearquivos,masissoéirrelevanteparaessaquestão.)AoperaçãoIRP_MJ_CREATEéemitidacomaopção"Generic Read", que de acordo com o MSDN é, na verdade, este conjunto de opções:

STANDARD_RIGHTS_READ, FILE_READ_DATA, FILE_READ_ATTRIBUTES, FILE_READ_EA, and SYNCHRONIZE.

A opção SYNCHRONIZE é a interessante aqui:

• For a caller to synchronize an I/O completion by waiting for the returned FileHandle, the SYNCHRONIZE flag must be set. Otherwise, a caller that is a device or intermediate driver must synchronize an I/O completion by using an event object.

Você também pode usar essa mesma API CreateFile para E / S assíncrona, mas é possível dizer que essa não é uma chamada assíncrona porque o sinalizador OVERLAPPED não está sendo usado.

CreateFile provides for creating a file or device handle that is either synchronous or asynchronous. A synchronous handle behaves such that I/O function calls using that handle are blocked until they complete, while an asynchronous file handle makes it possible for the system to return immediately from I/O function calls, whether they completed the I/O operation or not. As stated previously, this synchronous versus asynchronous behavior is determined by specifying FILE_FLAG_OVERLAPPED within the dwFlagsAndAttributes parameter.

Então, sim, milhares de usuários todos baixando simultaneamente um arquivo de 10 MB do seu site podem causar um impacto no desempenho do seu servidor. A principal estratégia do IIS para resolver isso é usando toneladas de threads. Esgotamento de threads e ajuste e dimensionamento de pool de threads são coisas reais que os administradores do IIS precisam conhecer. Se você tiver um site realmente grande, pode até entrar no jogo de mover seu conteúdo estático para um farm separado de servidores da Web devido ao limite de E / S versus limite de computação, etc. O ajuste de desempenho do IIS é um tópico muito complicado e específico do Serverfault A resposta é bem pedante no grande esquema das coisas. Por exemplo, é possível usar manipuladores assíncronos no IIS. Depende de como você escreve seu serviço / aplicativo da web.

    
por 10.12.2014 / 14:31