2009-11-19 7 views
5

Ich arbeite mit ASP.NET. IMHO, die asynchrone Programmierung in ASP.NET ist schön. Das heißt, wir können die BeginXXXX/EndXXXX-Paarmethode verwenden, um die Skalierbarkeit für ressourcenintensive Aufgaben zu verbessern.Warum nur ASP.NET asynchrones Programmiermodell haben?

Zum Beispiel muss eine Operation riesige Daten aus der Datenbank abrufen und auf der Antwortseite darstellen. Wenn wir diese Operation synchron haben. Der Thread, der diese Anfrage abgibt, ist für den gesamten Seitenlebenszyklus belegt. Da Threads Ressourcen begrenzt sind, ist es immer besser, den Betrieb mit I/O asynchron zu programmieren. Das heißt, ASP.NET weist Thread zu, um die BeginXXXX-Methode mit einer Callback-Funktion aufzurufen. Der Thread, der BeginXXXX aufruft, kehrt sofort zurück und kann angeordnet werden, um andere Anforderungen zu behandeln. Wenn der Job abgeschlossen ist, wird die Rückruffunktion ausgelöst und ASP.NET ruft EndXXXX auf, um die tatsächliche Antwort abzurufen.

Dieses asynchrone Programmiermodell kann die Threading-Ressourcen vollständig ausnutzen. Obwohl ThreadPool eine Beschränkung bietet, kann es tatsächlich viel mehr Anfragen verarbeiten. Wenn wir jedoch auf synchrone Weise programmieren und jede Anforderung eine lange I/O-Zeit benötigt, würden die konkurrierenden Anforderungen die Größe des Thread-Pools nicht überschreiten.

Vor kurzem habe ich Gelegenheit, andere Web-Entwicklungslösung wie PHP und Ruby on Rails zu erkunden. Zu meiner Überraschung haben diese Lösungen kein Gegenstück zum asynchronen Programmiermodell. Jede Anfrage wird für den gesamten Lebenszyklus von einem Thread oder Prozess bearbeitet. Das heißt, der Thread oder Prozess wird belegt, bevor das letzte Bit der Antwort gesendet wird.

Es gibt etwas, das asynchron ähnlich ist (http://netevil.org/blog/2005/may/guru-multiplexing), aber die Grundlinie ist, dass immer ein Thread oder Prozess für die Anfrage belegt ist. Dies ist nicht wie ASP.NET.

Also, ich frage mich: warum nicht diese beliebte Web-Lösung hat asynchrones Programmiermodell wie ASP.NET? Warum entwickelt sich nur ASP.NET zu einem asynchronen Ansatz?

Liegt das daran, dass PHP und Ruby-on-Rails hauptsächlich unter Linux bereitgestellt werden? Und Linux leidet nicht unter Prozess-/Thread-Performance-Problemen wie Microsoft Windows?

Oder gibt es tatsächlich asynchrone Lösung für PHP und Ruby-on-Rails, die ich nicht gefunden haben?

Danke.

+0

Ich bin in der gleichen Situation frage mich die gleiche Sache. Für so etwas wie eine Facebook-App, bei der viele Anfragen an die App externe Serviceanrufe ausführen, scheint die asynchrone Seitenverarbeitung einen viel besseren Durchsatz zu ermöglichen. Ich bin gespannt, wie sich Ruby on Rails vergleichen würde. –

+0

PHP kann asynchrone Anfragen an andere Dienste senden, aber die aktuelle Anfrage für die Thread-/Prozessbehandlung ist immer besetzt. Dies ist also nur für mehrere externe Serviceanrufe von Vorteil. –

Antwort

4

Ich habe keine definitive Antwort auf Ihre Frage, aber ich kann eine fundierte Vermutung machen.

Systeme wie PHP und Ruby sind so konzipiert, sehr plattformunabhängig sein, während ASP.NET tief in die Windows-Plattform integriert ist. Darüber hinaus ähnelt PHP eher einem alten ASP mit einem linearen, von Anfang bis Ende fließenden Ablauf.

Voll ASP.NET-Stil Asynchron-Seiten erfordern nicht nur Themen, sondern einheimische async I/O, um ihre maximale Wirkung eingesetzt werden. Async-E/A ist eine betriebssystemspezifische Funktion. Asynchrone Seiten beruhen auch auf dem Konzept eines Seitenlebenszyklus, der dem linearen Ablaufstil widerspricht. Ohne einen Seitenlebenszyklus wird es viel schwieriger, die Ergebnisse der Async-Aufrufe mit dem Rest Ihrer Seite zu integrieren.

Nur meine zwei Cent, YMMV.

Verwandte Themen