J'ai créé un ThreadPool personnalisé qui accepte les tâches du client, les traite et renvoie les résultats. Actuellement, cela fonctionne dans l'application MVC. Lorsque l'utilisateur télécharge le travail à exécuter à l'aide d'un formulaire, le serveur le traite et renvoie le rapport. Le traitement implique l'envoi de demandes SOAP à plusieurs services externes et l'accumulation de la réponse.Différence de performance énorme lorsque la même tâche est exécutée dans WCF auto-hébergé et dans MVC
Récemment, j'ai créé une application basée sur Windows qui peut automatiser les tâches de téléchargement et traitera également les rappels pour l'état actuel du travail. Ainsi j'ai implémenté un service WCF avec netTCPBinding & Contrat de rappel & Hébergé dans une application de console. Tout fonctionne bien, l'application Windows reçoit des rappels, etc. Mais le problème majeur est la performance. Cela prend 4 fois plus de temps pour traiter le même travail via la demande WCF que le téléchargement manuel via l'application MVC.
Initialement j'ai douté qu'il soit en retard dans la communication donc j'ai mis en place un chronomètre pour trouver la durée de chaque étape. Étonnamment, le retard n'est pas dû au retard de communication, il se produit est la dernière routine qui fait des demandes SOAP aux services externes. À mon avis, cela est indépendant du mode de transport de Job du client au serveur et cela fonctionne également dans des threads séparés dans ThreadPool personnalisé. J'utilise Same API dans l'application MVC et le service WCF. Logique, Routine tout est pareil. Mon deuxième doute était de savoir si WCF interrompt/suspend les threads en cours pour traiter de nouvelles demandes?
Quelqu'un peut-il avoir un aperçu de ce qui pourrait être la raison? Je peux fournir plus d'informations en fonction de ce qui est requis.
Merci à l'avance pour l'aide
+1 J'aimerais aussi savoir ... –