1) Sembra consigliabile disporre di un pool di applicazioni per sito Web. Ci sono avvertenze su questo approccio? Un pool di applicazioni, ad esempio, può racchiudere tutta la CPU, la memoria, ecc ...?
Questo è un approccio piuttosto valido; non ci sono buoni motivi a cui posso pensare di avere diversi "siti" (applicazioni) che condividono lo stesso pool. A meno che non debbano condividere una singola risorsa di qualche tipo. Un'applicazione potrebbe teoricamente contenere molta CPU o memoria, ma cambiare il modo in cui le applicazioni vengono messe in comune non influirà molto su questo.
2) Quando è necessario consentire più processi di lavoro in un pool di applicazioni. Quando non dovresti?
È meglio lasciarlo solo, usando le impostazioni predefinite. A meno che tu non sappia davvero cosa stai facendo, questo può effettivamente avere un impatto negativo sul tuo sito Web / applicazione.
3) È possibile utilizzare il limite di memoria privata per impedire a un pool di applicazioni di interferire con un altro? L'impostazione su un valore troppo basso causerà richieste valide per riciclare il pool di applicazioni senza ottenere una risposta valida?
a) Teoricamente
b) Sì, impostarlo su Abbassa può avere effetti negativi. Ancora una volta, a meno che tu non abbia esigenze specifiche e non sappia cosa stai facendo, lascia queste da sole.
4) Qual è la differenza tra i limiti di memoria privata e virtuale?
È molto complicato, ecco un breve post che ho trovato che potrebbe aiutare: http://cybernetnews.com/cybernotes-windows-memory-usage-explained/
5) Esistono validi motivi per NON eseguire un pool di applicazioni per sito?
Ancora una volta, l'unica ragione a cui riesco a pensare è se c'è una sorta di "risorsa condivisa" di cui hanno bisogno le applicazioni multiple, quindi vorresti eseguirle nello stesso processo.
Per applicazioni e siti Web per scopi generici, IIS è abbastanza ben impostato con i suoi valori predefiniti.
****AGGIORNARE****
Per quanto riguarda la tua richiesta di ulteriori informazioni su # 2, non dovresti farlo a meno che tu non abbia una specifica necessità di farlo. Anche con azioni del server che richiedono molto tempo, le richieste vengono servite utilizzando più thread e si desidera utilizzare "Richieste asincrone" per gestire attività di lunga durata (che libera un thread del pool di thread per gestire altre richieste). Realisticamente, non riesco a pensare a nessuna buona ragione per consentire più processi per un singolo pool.
Una volta che inizi a parlare di più processi, allora potresti imbatterti in cose come: perdere lo stato della sessione perché una sessione è viva nel processo 1, ma la richiesta viene gestita dal processo 2. O peggio ancora, devi capire come fare alcune comunicazioni tra processi, il che è un vero dolore.
Indipendentemente da cosa vieni in merito a un motivo per più processi, sarei disposto a scommettere che esiste un modo migliore per affrontarlo (piuttosto che avviare un altro processo).