IIS7: serve solo una pagina alla volta. È una cosa che mi rende felice!

Question

Situazione: applicazione ASP classica, utilizzando un pool di applicazioni personalizzato. Impostazioni predefinite.

Su alcune macchine IIS7, IIS decide di servire solo una pagina alla volta. Quindi se carichi più pagine da un sito, ognuna deve essere caricata in successione.

ad es. Se carico http://foo.com/default.asp da un browser, e da un altro computer carico http://foo.com/differenturl.asp, il primo deve finire prima che l'altro venga caricato. È quasi come se il processo w3p fosse a thread singolo.

Nota: esiste un'impostazione denominata MaxProcesses in Impostazioni avanzate per IIS che dice "Imposta questo valore maggiore di 1 per creare un giardino Web" (qualunque sia). Questo NON risolve il problema perché genera più processi con il proprio stato di sessione ecc. E quando carichi http://foo.com/default.asp non c'è modo di garantire che tu venga assegnato allo stesso processo.

Il problema si è rivelato perché abbiamo una pagina di diagnostica scritta in ASP che crea e controllo ActiveX che carica un URL sul sito Web e restituisce i risultati.

Quindi, diagnostica.asp carica e nel codice sul lato server crea un piccolo controllo Web che carica (si pensi al controllo XMLHTTP) default.asp sullo stesso server.

Questa pagina non avrà MAI terminato il caricamento, perché il server è in attesa della fine della pagina diagnostics.asp prima di servire la pagina default.asp. Deadlock!

Questo funziona perfettamente su ogni macchina IIS6, e credo che ci siano alcuni server IIS7 in cui funziona anche bene.

Ho verificato che non è un risultato della nostra bizzarra diagnostica. Il caricamento di più schede da una macchina o anche da macchine separate mostrerà che il processo Web le gestisce una alla volta.

---

Risposta corretta da AnthonyWJones: il debug lato server è stata attivata in IIS7. Questo mette IIS in modalità single threaded.

Answer 1

Nel gestore IIS fare clic sull'applicazione nell'albero.

Fare doppio clic su ASP nella sezione IIS.

Expand "Proprietà di debug"

Garantire sia "Attiva debug sul lato client" e "Attivare il debug lato server" sono impostati su false.

Quando il debug è abilitato ASP è limitato all'elaborazione di una richiesta alla volta in una singola modalità di thread.

Answer 2

IIS7 è in genere più thread multipli, quindi suppongo che ci sia un problema con l'app.

Hai citato ActiveX per caricare una pagina dallo stesso server, forse questo ActiveX non è libero da thread e questo fa sì che ogni pagina che lo utilizza esegua una singola istanza?

BTW: Web Giardino - stesso server useing più processi - non può usare inprocess sessione Web Farm - più server Web

Answer 3

Assicurarsi che asp.net è configurato per utilizzare più di 1 thread di lavoro. This msdn article spiega come impostare questa opzione di configurazione.

Answer 4

Prima di tutto: assicurarsi di testarlo con più client. Un singolo computer esegue contemporaneamente solo 2 richieste HTTP sullo stesso server (indirizzo IP). (Questa è una spe- cificazione RFC)

Se ciò non risolve il problema, date un'occhiata in IIS7 -> ASP -> Servizi -> Proprietà COM Plus -> Esegui in MTA. Prova a impostare questa impostazione su "True".

Spero che questo aiuti.

Answer 5

Sei sicuro di non avere una dipendenza dal codice che causa il deadlock. Ho visto questo prima dove la registrazione, le connessioni SQL ecc. Crea una dipendenza. Usa perfmon e controlla la coda di lettura/scrittura del disco rigido, la coda di lettura/scrittura della memoria per vedere se il backup è in corso.

Consiglio vivamente il blog Tess Ferrandez's (ASP.NET Escalation Engineer - Microsoft) per un sacco di approfondimenti e modo per scoprire cosa sta succedendo. Tess ha dimenticato di più su questa roba che la maggior parte della gente saprà mai.

Penso che il tuo problema non sia collegato a IIS ma qualcosa nella tua app, probabilmente nel tuo componente ActiveX. Assicurati di ripulire dopo il componente ActiveX. Ecco un pezzo di codice che uso per ripulire dopo aver usato Excel (un altro componente Com). Ricorda Com non è gestito.

Private Sub ShutDownExcel() 
    If objExcel IsNot Nothing Then 
     objExcel.DisplayAlerts = True 
     objExcel.Quit() 
     System.Runtime.InteropServices.Marshal.ReleaseComObject(objExcel) 
     objExcel = Nothing 
    End If 

    ' Clean up memory so Excel can shut down. 
    GC.Collect() 
    GC.WaitForPendingFinalizers() 

    ' The GC needs to be called twice in order to get the 
    ' Finalizers called - the first time in, it simply makes 
    ' a list of what is to be finalized, the second time in, 
    ' it actually the finalizing. Only then will the 
    ' object do its automatic ReleaseComObject. 
    GC.Collect() 
    GC.WaitForPendingFinalizers() 
End Sub 

Spero che questo aiuti.

Answer 6

Hai modificato "Modalità pipeline gestita" su Pool di applicazioni su "Classico" (l'impostazione predefinita è "Integrato")? Altrimenti, prova con il classico.

Non so se sarebbe di aiuto in alcun modo. Ho da tempo smesso di lottare per far funzionare le classiche applicazioni ASP con IIS7. (Non che io possa dire, le app sono veramente belle e corrette, ma hanno funzionato nelle versioni precedenti)

E provare a disattivare il buffering per le pagine di test e farle sputare qualcosa in ogni iterazione. Il buffering (e il caching) potrebbe essere cambiato in IIS7. Forse sono elaborati in modo concorrente dopotutto e semplicemente i buffer sono troppo grandi per vedere la differenza.

Questo è tutto ciò che mi viene in mente in questo momento.

---

Presumo che si stia testando con un caso molto semplice. L'app non esegue (né le pagine di test né global.asa) utilizza oggetti strani che sono comuni a entrambe le richieste e quindi necessita di un blocco.

Answer 7

Solo un pensiero ma se si visita il sito Web in IIS, fare clic sul collegamento Limiti ... a sinistra, a quali limiti di connessione è impostato? C'è sia una larghezza di banda massima e le opzioni di connessione simultanea massima lì.

Vorrei anche andare al Pool di app e fare clic su Impostazioni avanzate ... e controllare i limiti di CPU e memoria. Probabilmente anche creando un nuovo pool di app da zero con Nessun codice gestito selezionato per eliminarlo.

Answer 8

Se non si tratta di un problema con le impostazioni di debug, ho riscontrato che si può verificare un comportamento simile quando si utilizzano le variabili di sessione in ASP in IIS 8.

Non so che questo è specifico di IIS 8, ma "ASP garantisce che solo una richiesta da una sessione verrà eseguita in qualsiasi momento." http://msdn.microsoft.com/en-us/library/ms972335.aspx