Perché solo ASP.NET ha un modello di programmazione asincrona?

Question

Funziono con ASP.NET. IMHO, il supporto per la programmazione asincrona in ASP.NET è bello. Cioè, possiamo avere il metodo di coppia BeginXXXX/EndXXXX per migliorare la scalabilità per task ad alta intensità di risorse.

Ad esempio, un'operazione deve ottenere enormi dati dal database e visualizzarli nella pagina Web di risposta. Se abbiamo questa operazione sincrona. Il thread che gestisce questa richiesta sarà occupato per l'intero ciclo di vita della pagina. Poiché i thread sono risorse limitate, è sempre meglio programmare l'operazione con I/O in modo asincrono. Cioè, ASP.NET allocherà thread per richiamare il metodo BeginXXXX con una funzione di callback. Il thread richiama BeginXXXX restituisce immediatamente e può essere organizzato per gestire altre richieste. Al termine del lavoro, la funzione di callback viene attivata e ASP.NET invocherà EndXXXX per ottenere la risposta effettiva.

Questo modello di programmazione asincrona può sfruttare appieno le risorse di threading. Anche se esiste un limite di ThreadPool, può effettivamente gestire molte più richieste. Tuttavia, se programmiamo in modo sincrono e ogni richiesta richiede lunghi I/O, le richieste simultanee non superano le dimensioni del pool di thread.

Recentemente, ho la possibilità di esplorare altre soluzioni di sviluppo web come PHP e Ruby on Rails. Con mia sorpresa, queste soluzioni non hanno controparti del modello di programmazione asincrona. Ogni richiesta viene gestita da un thread o processo per l'intero ciclo di vita. Cioè, il thread o processo è occupato prima che venga inviato l'ultimo bit di risposta.

C'è qualcosa di simile in modo asincrono (http://netevil.org/blog/2005/may/guru-multiplexing), ma la linea di base è che c'è sempre un thread o un processo occupato per la richiesta. Questo non è come ASP.NET.

Quindi, mi chiedo: perché queste popolari soluzioni Web non hanno un modello di programmazione asincrono come ASP.NET? Perché solo ASP.NET si evolve per utilizzare un approccio asincrono?

Forse perché PHP e Ruby-on-Rails sono distribuiti principalmente in Linux? E Linux non subisce penalità sulle prestazioni di processo/thread come Microsoft Windows?

Oppure, esiste effettivamente una soluzione asincrona per PHP e Ruby-on-Rails che non ho trovato?

Grazie.

Answer 1

Non ho una risposta definitiva alla tua domanda, ma posso fare un'ipotesi plausibile.

Sistemi come PHP e Ruby sono progettati per essere indipendenti dalla piattaforma, mentre ASP.NET è profondamente integrato nella piattaforma Windows. Inoltre, PHP è più simile all'ASP vecchio stile, con un flusso lineare dall'inizio alla fine.

Le pagine asincrone in stile ASP.NET richiedono non solo i thread, ma anche l'I/O asincrono nativo da utilizzare per il massimo impatto. Async I/O è una funzionalità specifica del sistema operativo. Le pagine asincrone si basano anche sul concetto di un ciclo di vita della pagina, che è un anatema per lo stile del flusso lineare. Senza un ciclo di vita della pagina, diventa molto più difficile integrare i risultati delle chiamate asincrone con il resto della pagina.

Solo i miei due centesimi, YMMV.