Je travaille avec ASP.NET. À mon humble avis, le support de la programmation asynchrone dans ASP.NET est magnifique. Autrement dit, nous pouvons avoir la méthode de paire BeginXXXX/EndXXXX pour améliorer l'évolutivité pour une tâche gourmande en ressources. Par exemple, une opération doit extraire des données importantes de la base de données et les restituer sur une page Web de réponse. Si nous avons cette opération synchrone. Le thread qui transmet cette requête sera occupé pendant tout le cycle de vie de la page. Puisque les threads sont des ressources limitées, il est toujours préférable de programmer le fonctionnement avec E/S de manière asynchrone. En d'autres termes, ASP.NET alloue thread pour appeler la méthode BeginXXXX avec une fonction de rappel. Le thread appelle BeginXXXX renvoie immédiatement et peut être organisé pour gérer d'autres demandes. Lorsque le travail est terminé, la fonction de rappel est déclenchée et ASP.NET invoquera EndXXXX pour obtenir la réponse effective.Pourquoi seul ASP.NET a un modèle de programmation asynchrone?
Ce modèle de programmation asynchrone peut tirer pleinement parti des ressources de thread. Même s'il y a une limite de ThreadPool, il peut gérer beaucoup plus de requêtes. Toutefois, si nous programmons de manière synchrone et que chaque requête nécessite de longues E/S, les demandes simultanées ne dépasseront pas la taille du pool de threads. Récemment, j'ai eu l'occasion d'explorer d'autres solutions de développement Web telles que PHP et Ruby on Rails. À ma grande surprise, ces solutions n'ont pas de contrepartie du modèle de programmation asynchrone. Chaque demande est gérée par un fil ou un processus pour l'ensemble du cycle de vie. C'est-à-dire que le thread ou le processus est occupé avant que le dernier bit de réponse ne soit envoyé.
Il y a quelque chose de similaire à asynchrone (http://netevil.org/blog/2005/may/guru-multiplexing), mais la ligne de base est qu'il y a toujours un thread ou un processus occupé pour la requête. Ce n'est pas comme ASP.NET. Donc, je me demande: pourquoi ces solutions web populaires n'ont-elles pas de modèle de programmation asynchrone comme ASP.NET? Pourquoi seul ASP.NET évolue pour utiliser l'approche asynchrone?
Est-ce parce que PHP et Ruby-on-Rails sont principalement déployés sous Linux? Et Linux ne souffre pas de la peine de performance processus/thread comme Microsoft Windows?
Ou, y a-t-il réellement une solution asynchrone pour PHP et Ruby-on-Rails que je n'ai pas trouvée?
Merci.
Je suis dans la même situation en me demandant la même chose. Pour quelque chose comme une application Facebook, où de nombreuses demandes à l'application font des appels de service externes, le traitement de la page asynchrone semble permettre un meilleur débit. Je suis curieux de savoir comment Ruby on Rails se comparerait. –
PHP peut faire une requête asynchrone à d'autres services, mais la demande courante de gestion de processus/processus est toujours occupée. Ainsi, cela ne profite qu'à plusieurs appels de service externes. –