2009-11-19 8 views
5

Współpracuję z ASP.NET. IMHO, asynchroniczne wsparcie programistyczne w ASP.NET jest piękne. Oznacza to, że możemy mieć metodę BeginXXXX/EndXXXX pair, aby poprawić skalowalność zadania wymagającego intensywnego użycia zasobów.Dlaczego tylko ASP.NET ma asynchroniczny model programowania?

Na przykład jedna operacja musi uzyskać ogromne dane z bazy danych i renderować je na stronie internetowej odpowiedzi. Jeśli mamy tę operację synchroniczną. Wątek przekazujący to żądanie będzie zajęty przez cały cykl życia strony. Ponieważ wątki są zasobami ograniczonymi, zawsze lepiej jest programować operacje z I/O w sposób asynchroniczny. Oznacza to, że program ASP.NET przydzieli wątek, aby wywołać metodę BeginXXXX z funkcją wywołania zwrotnego. Wątek powoduje natychmiastowe wywoływanie BeginXXXX i może być dostosowany do obsługi innych żądań. Po zakończeniu zadania wywoływana jest funkcja wywołania zwrotnego, a program ASP.NET wywoła funkcję EndXXXX, aby uzyskać faktyczną odpowiedź.

Ten asynchroniczny model programowania może w pełni korzystać z wątków zasobów. Mimo że istnieje limit ThreadPool, może on obsługiwać znacznie więcej żądań. Jeśli jednak programujemy synchronicznie, a każde żądanie wymaga długich operacji we/wy, żądania współbieżne nie przekraczają wielkości puli wątków.

Ostatnio mam okazję poznać inne rozwiązania do projektowania stron internetowych, takie jak PHP i Ruby on Rails. Ku mojemu zaskoczeniu, te rozwiązania nie mają odpowiednika asynchronicznego modelu programowania. Każde żądanie jest obsługiwane przez jeden wątek lub proces przez cały cykl życia. Oznacza to, że wątek lub proces są zajęte zanim wysłany zostanie ostatni bit odpowiedzi.

Istnieje coś podobnego do asynchronicznego (http://netevil.org/blog/2005/may/guru-multiplexing), ale linia bazowa jest taka, że ​​zawsze jest jeden wątek lub proces zajęty dla żądania. To nie jest tak jak ASP.NET.

Tak, zastanawiam się: dlaczego te popularne rozwiązania internetowe nie mają asynchronicznego modelu programowania, takiego jak ASP.NET? Dlaczego tylko ASP.NET ewoluuje do korzystania z asynchronicznego podejścia?

Czy to dlatego, że PHP i Ruby-on-Rails są najczęściej wdrażane w systemie Linux? A Linux nie cierpi na karę wydajności procesu/wątku, taką jak Microsoft Windows?

Czy jest tak naprawdę rozwiązanie asynchroniczne dla PHP i Ruby-Rails, których nie znalazłem?

Dzięki.

+0

Jestem w tej samej sytuacji, zastanawiasz się nad tym samym. W przypadku aplikacji na Facebooka, gdzie wiele zgłoszeń do aplikacji wykonuje zewnętrzne wywołania serwisowe, przetwarzanie asynchronicznych stron wydaje się mieć znacznie lepszą przepustowość. Ciekawi mnie porównanie Ruby on Rails. –

+0

PHP może wykonywać asynchroniczne żądania do innych usług, ale bieżące żądanie obsługi wątku/procesu jest zawsze zajęte. Ta zaleta odnosi się tylko do wielu zewnętrznych zgłoszeń serwisowych. –

Odpowiedz

4

Nie mam jednoznacznej odpowiedzi na twoje pytanie, ale mogę zgadnąć.

Systemy takie jak PHP i Ruby są zaprojektowane tak, aby były bardzo niezależne od platformy, a ASP.NET jest głęboko zintegrowany z platformą Windows. Ponadto PHP przypomina bardziej staromodną ASP, z linearnym przepływem od początku do końca.

Pełne strony asynchroniczne w stylu ASP.NET wymagają nie tylko wątków, ale natywnych asynchronicznych operacji we/wy, aby uzyskać maksymalny efekt. Asynchroniczne operacje we/wy są opcjami specyficznymi dla systemu operacyjnego. Strony asynchroniczne również opierają się na koncepcji cyklu życia strony, co jest przekleństwem dla liniowego stylu przepływu. Bez cyklu życia strony znacznie trudniej będzie zintegrować wyniki asynchronicznych połączeń z resztą strony.

Tylko moje dwa centy, YMMV.

Powiązane problemy