Normalmente, não, mas depende do motivo das exceções e se a causa raiz está (ou está quebrando) um recurso compartilhado.
Em um mundo típico de site da Web padrão, nada compartilhado, cada W3WP tem seu próprio espaço de memória, tabela de manipulação e recursos associados, e eles são exclusivos do processo. Um cai, ninguém se importa. (De fato: na verdade, se é realmente o site padrão, ou seja, somente conteúdo estático, um acidente seria incrivelmente estranho e um bom indicador de que algo realmente errado está acontecendo na caixa ).
Se o aplicativo da web optar por usar recursos (digamos, uma tabela de banco de dados ou um arquivo em algum lugar no disco) e vários aplicativos da Web consumirem o mesmo recurso, um problema em um pode levar indiretamente a um problema em outros.
Por exemplo: aquela consulta SQL extremamente dispendiosa que você iniciou no processo A, da qual você não detectou a exceção de tempo limite, ainda está amarrando o mesmo servidor de banco de dados usado pelos processos BC e D , que estão indo para um tempo limite também ...
Ou, se um aplicativo da Web faz chamadas HTTP para outro Pool de aplicativos na mesma caixa, então sim, isso é uma dependência clara e um caso claro em que há um problema!
Mas, geralmente, onde há um caso em que tudo corre mal de uma só vez, se você estiver executando mais de um aplicativo da web, é improvável que a causa ... a causa é mais provável de ser outro software, 90% do tempo com um componente do modo kernel, rodando na caixa.
Os principais exemplos são: Coisas que dependem de compartilhamentos SMB (ou seja, conteúdo em \ server \ share), particularmente quando o destino é um emulador SMB não Windows (portanto, não compatível com bug) ou outro driver interessante de filtro IO está em uso. .. que perfeitamente nos leva ao antivírus e filtrar drivers dessa natureza ... Os drivers do modo K captam o acesso ao arquivo, redirecionam o pedido por meio de um processo de modo-u que fica ocupado ou cruzado, causando um atraso no modo-IO , causando diversão sem fim). (Menção honrosa a dificuldades de autenticação causadas por interrupções de infra-estrutura de autenticação).
Ainda assim, isso é apenas adivinhação sem nenhum dado, então o melhor primeiro passo é pegar os despejos de memória (DebugDiag ou Gerenciador de Tarefas), alimentá-los no DebugDiag ou em uma brolleague amigável com Windbg e tentar identificá-los se há uma causa do modo de usuário para o atraso.
Se não houver, você passa para a solução de problemas do modo k, e as coisas ficam um pouco confusas (mais comumente, marcar a caixa azul para obter um despejo de memória do modo k enquanto a estranheza está em andamento).