Tout le monde sait que l'asynchronie offre un « meilleur débit », une « meilleure scalabilité » et une consommation de ressources plus efficace. Je pensais aussi de cette façon (simpliste) avant de réaliser l'expérience ci-dessous. Elle indique essentiellement que si l'on prend en compte tous les surcoûts liés au code asynchrone et qu'on les compare à un code synchrone correctement configuré, on obtient peu voire aucun avantage en termes de performances/débit/consommation de ressources.
La question : le code asynchrone offre-t-il vraiment de bien meilleures performances par rapport au code synchrone avec un pool de threads correctement configuré ? Peut-être que mes tests de performance
Le modèle asynchrone apporte-t-il vraiment des avantages en débit par rapport à un modèle synchrone correctement configuré ?
Re: Le modèle asynchrone apporte-t-il vraiment des avantages en débit par rapport à un modèle synchrone correctement configuré ?
Tout le monde sait que l'asynchronie offre un « meilleur débit », une « meilleure scalabilité » et une consommation de ressources plus efficace.
Scalabilité, oui. Débit : cela dépend. Chaque requête asynchrone est *plus lente* que la requête synchrone équivalente, donc vous ne constaterez un avantage en débit que lorsque la scalabilité entre en jeu (c'est-à-dire lorsqu'il y a plus de requêtes que de threads disponibles).
Le code asynchrone offre-t-il vraiment de bien meilleures performances par rapport au code synchrone avec un pool de threads correctement configuré ?
Eh bien, le piège réside dans « pool de threads correctement configuré ». Ce que vous supposez
Scalabilité, oui. Débit : cela dépend. Chaque requête asynchrone est *plus lente* que la requête synchrone équivalente, donc vous ne constaterez un avantage en débit que lorsque la scalabilité entre en jeu (c'est-à-dire lorsqu'il y a plus de requêtes que de threads disponibles).
Le code asynchrone offre-t-il vraiment de bien meilleures performances par rapport au code synchrone avec un pool de threads correctement configuré ?
Eh bien, le piège réside dans « pool de threads correctement configuré ». Ce que vous supposez