Pool di applicazioni separati per applicazioni ASP.net in IIS

Question

Ho letto i consigli su come creare pool di applicazioni separati per ogni applicazione asp.net sul nostro server Win2008.

Abbiamo circa 20 app sullo stesso server. So che questo creerebbe 20 processi separati per i lavoratori, il che sembra molto dispendioso.

È buona prassi creare pool di applicazioni separati per ciascuna applicazione?

Answer 1

Ripubblicato da ServerFault, "Why add additional application pools in IIS?"

• AppPools possono funzionare come diverse identità, in modo da poter limitare le autorizzazioni in questo modo.
• È possibile assegnare un'identità diversa a ciascun pool di app in modo che quando si esegue il task manager, si sappia quale w3wp.exe è quale.
• È possibile riciclare/riavviare un pool di app senza influire sui siti in esecuzione in pool di app diversi.
• Se si dispone di un sito web che ha una perdita di memoria o in generale si comporta male, è possibile inserirlo in un pool di applicazione in modo da non influenzare gli altri siti web
• Se si dispone di un sito web che è molto impegnativo per la CPU-(come ridimensionare le foto, ad esempio), è possibile collocarlo nel proprio pool di app e limitare l'utilizzo della CPU
• Se si dispone di più siti Web ciascuno con il proprio database SQL, è possibile utilizzare l'autenticazione di directory attiva invece di memorizzare nomi utente/password in web.config.

Answer 2

Se le tue app sono stabili e non usano molta memoria, allora direi che va bene metterle nello stesso pool di app. I pool di app ti offrono isolamento tra le tue applicazioni.

Answer 3

Uno dei motivi principali che considero quando si creano pool di app è la gestione dei processi. Esistono altri motivi, ad esempio la sicurezza, ecc. Quando un'applicazione in hosting di IIS viene arrestata, elimina anche il processo host. Nelle versioni precedenti di IIS ciò significava che tutte le attività Web si bloccavano insieme. Con i pool di app puoi isolare le tue applicazioni l'una dall'altra. Se uno ha una perdita di memoria e continua a bloccarsi, le altre app continueranno a funzionare.

Answer 4

Il vantaggio principale della creazione di diversi pool di applicazioni è che è possibile fornire ad ogni pool altre credenziali. Le 20 applicazioni possono comunicare con 20 database diversi che richiedono tutti un altro accesso. La procedura migliore è quindi eseguire ciascuna applicazione utilizzando un account di servizio diverso.

Non mi preoccuperei troppo delle prestazioni. La maggior parte del tempo verrà probabilmente spesa all'interno di ogni applicazione Web, indipendentemente dal processo in cui ciascuna applicazione si trova.

Answer 5

Questo dipende in realtà dalle applicazioni, dal modello di sicurezza e da quanto ci si fida delle applicazioni.

Ecco alcune cose che dico sempre alle persone quando si lavora con i pool di applicazioni.

• Utilizzare pool di applicazioni separati se ogni applicazione richiede un accesso diverso alle risorse di sistema. (Può utilizzare più account di processo)
• Se un'applicazione è una risorsa hog, mission critical o "sconosciuta", è meglio inserirla nel proprio pool per isolarla dal resto del sistema

Answer 6

sì, è una buona idea anche per 20 applicazioni.

1. Sicurezza. Diversi pool di app in esecuzione con account diversi.
2. Isolamento. Un'app che si blocca non bloccherà altre app.
3. Memoria (se si utilizza 32 bit). Ogni pool di app avrà il proprio spazio di indirizzamento. In questo modo è possibile indirizzare molta più memoria di un massimo di circa 2,7 GB di spazio utilizzabile per 1 processo.
4. È possibile scegliere di riavviare periodicamente un'app che si comporta in modo non corretto, senza influire sulle altre applicazioni.

Answer 7

Separare le app nei pool è una buona cosa da fare quando c'è un motivo, e ci sono una serie di buoni motivi sopra elencati. Ci sono, tuttavia, buoni motivi per non separare le app in diversi pool.

Le app che utilizzano lo stesso accesso, la versione .NET, ecc. Funzioneranno in modo più efficiente in un singolo pool e saranno mantenute più facilmente. Il più fastidioso, IIS ucciderà i pool di applicazioni inattivi, richiedendo la ricreazione del pool su ogni utilizzo. Se si isolano le app utilizzate di rado, si imporrà un costo di avvio non necessario per gli utenti. La combinazione di queste app in un unico pool renderà gli utenti più felici quando non pagheranno i costi di avvio, i server più felici quando non daranno memoria a più processi e fette di CPU per loro, e amministratori più felici quando devono gestire meno app piscine.

Answer 8

Avevo 58 siti Web .Net e 17 vecchi siti Web ASP classici sullo stesso server IIS7.5 utilizzando pool di app separati per ogni sito. Ho notato che la compressione di IIS si è interrotta a intermittenza, causando il danneggiamento dei fogli di stile circa il 5% delle volte. Guardando il task mamanger sul server, ho potuto vedere che il server si stava avvicinando al limite di 4 GB di ram: ogni processo di w3wp.exe richiedeva fino a 100 MB di memoria, a seconda della quantità di traffico che il sito stava ottenendo. Ho quindi spostato tutti i siti Web in due soli pool di applicazioni (uno per i siti Web .net 4 e uno per i vecchi siti ASP classici) e la memoria totale utilizzata dopo il passaggio da 3,8 GB a poco meno di 2,8 GB - risparmiando oltre 1 GB di memoria spazio sul server. Dopo la modifica (e lasciando il server in esecuzione per un paio d'ore per tornare ai normali livelli di traffico), i processi di w3wp utilizzavano 300 MB per tutti i siti Web .net e 20 MB per i classici siti Web ASP. Potrei riattivare la compressione IIS di nuovo senza problemi.

L'utilizzo di pool di APP separati è una grande idea per molte delle ragioni menzionate negli altri post precedenti, ma anche nella mia esperienza provoca un sovraccarico di memoria molto più elevato se si ospita un numero equo di siti Web sullo stesso server.

Immagino che sia un compromesso tra restrizioni hardware e sicurezza se si desidera utilizzare pool di app separati. È una buona idea se hai le risorse per farlo.