Qualcuno può spiegare le differenze, in IIS, tra pool di applicazioni, processi di lavoro e domini di app? Inoltre, come funzionano insieme? Ho letto un paio di articoli ma è ancora un po 'confuso.
Risposte:
Provo a dirle con altre parole.
In un server puoi avere molti siti asp.net che vengono eseguiti insieme. Ogni sito è un dominio dell'app .
È necessario assegnare a ciascuno di essi un pool di applicazioni . Molti domini applicazione (siti) possono avere lo stesso pool di applicazioni e, poiché hanno lo stesso pool di applicazioni, vengono eseguiti con gli stessi processi e con lo stesso account e hanno le stesse impostazioni del pool. Se questo pool si riavvia, tutti i siti in quel pool vengono riavviati.
Ora ogni pool può avere uno o più processi di lavoro . Ogni processo di lavoro è un programma diverso che esegue il tuo sito, ha le proprie variabili statiche, chiamate di arresto di avvio diverse, ecc. Processi di lavoro diversi non comunicano insieme e l'unico modo per scambiare dati è da file comuni o da un database comune. Se hai più di un processo di lavoro e uno di essi esegue calcoli a lungo termine, l'altro può occuparsi di gestire le chiamate Internet e mostrare i contenuti.
Quando si assegnano molti processi di lavoro a un singolo pool, si crea il web garden chiamato e il sito è come essere eseguito da più di un computer se un computer è una macchina di elaborazione.
Ogni processo di lavoro può avere molti thread.
In che modo il processo di lavoro più influisce su di te:
quando hai un processo di lavoro tutto è più semplice, tra le tue applicazioni tutte le variabili statiche sono le stesse e usi il lockper sincronizzarle.
Quando assegni più di un processo di lavoro, continui comunque a utilizzare le lockvariabili statiche, le variabili statiche non sono diverse tra le molte esecuzioni del tuo sito e se hai qualche risorsa comune (ad esempio la creazione di una miniatura sul disco) quindi devi sincronizzare il tuo processo di lavoro con Mutex.
Ancora una nota. Sembra che quando esegui più processi di lavoro, potresti avere caricamenti di pagine asincroni più fluidi. C'è un piccolo problema con il gestore della sessione di asp.net che blocca l'intero processo per il caricamento di una pagina - che è buono e non buono dipende se lo conosci e lo gestisci - o lo modifichi.
Quindi parliamo di un solo sito con molti processi di lavoro. Qui affronti il problema con cui devi sincronizzare la modifica delle risorse comuni Mutex. Ma le pagine / gestori che usano la sessione non sono asincroni perché la sessione li blocca. Questo è un bene per iniziare perché eviti di fare questa sincronizzazione di molti punti da solo.
Alcune domande su questo argomento:
App Web bloccata durante l'elaborazione di un'altra app Web durante la condivisione della stessa sessione Le
chiamate jQuery Ajax al servizio Web sembrano essere sincrone
ASP.NET Server non elabora le pagine in modo asincrono
Sostituendo completamente la sessione di ASP.Net
Ora questo blocco di sessione non ha effetto su siti diversi.
Tra i diversi siti il processo più elaborato può aiutare a non bloccare un sito con un processo di lunga durata.
Inoltre, tra diversi siti anche più pool possono essere d'aiuto, perché ogni pool ha almeno un processo funzionante, ma ricorda e guarda da solo usando l'esploratore di processi, ogni processo di lavoro richiede più memoria del tuo computer e un grande server con 16G di memoria e un server SQL non può avere troppi processi lavorati diversi, ad esempio su un server con 100 siti condivisi, non è possibile avere 100 pool diversi.
Il significato per gli sviluppatori ASP.NET: per rendere il tuo sito web scalabile, non utilizzare sessioni in-process e non utilizzare il blocco delle variabili di classe statica per la sincronizzazione.
Sì, anche se non tutte le applicazioni sono un sito web. Puoi avere un'applicazione nidificata sotto un sito web.
Sì, ogni applicazione deve avere un processo di lavoro (pool di applicazioni), sebbene un pool di applicazioni possa server più applicazioni. È possibile distribuire una singola applicazione Web (giardino Web / fattoria), il che significa che verrà eseguita in più processi.
Ogni processo verrà eseguito nel proprio dominio app (ogni pool di applicazioni è un dominio app separato).
Da MSDN.
Un'applicazione è un raggruppamento di contenuto al livello principale di un sito Web o un raggruppamento di contenuto in una cartella separata nella directory principale del sito Web.
Un pool di applicazioni definisce un gruppo di uno o più processi di lavoro, configurati con impostazioni comuni che servono le richieste a una o più applicazioni assegnate a quel pool di applicazioni. Poiché i pool di applicazioni consentono a una serie di applicazioni Web di condividere uno o più processi di lavoro configurati in modo simile, forniscono un modo conveniente per isolare una serie di applicazioni Web da altre applicazioni Web sul computer server. I confini del processo separano ogni processo di lavoro; pertanto, i problemi delle applicazioni in un pool di applicazioni non influiscono sui siti Web o sulle applicazioni in altri pool di applicazioni. I pool di applicazioni aumentano in modo significativo sia l'affidabilità che la gestibilità dell'infrastruttura Web.
Dal collegamento di origine: -http: //weblogs.asp.net/owscott/archive/2007/09/02/application-vs-appdomain.aspx
Un'applicazione è un termine IIS, ma è quello utilizzato da ASP.NET. Essenzialmente crea una sandbox, o una serie di confini per separare diversi siti, o parti di siti, dagli altri.
Un AppDomain è un termine .NET. (In IIS7, AppDomains gioca un ruolo più importante all'interno di IIS, ma per la maggior parte è un termine ASP.NET)
Il processo di lavoro viene utilizzato per elaborare la richiesta dell'applicazione Web.