J'ai vu des applications hébergées en tant que dotnet.exe tandis que mon application avec
WebHost
.CreateDefaultBuilder(args)
.UseConfiguration(config)
//.UseContentRoot(Directory.GetCurrentDirectory())
.UseEnvironment(environment)
//.UseIIS() //even commented those; still no effort
//.UseIISIntegration()
.UseStartup<Startup>()
simple s'exécute en tant que w3wp.exe .
Quelle est la différence et comment changer? Je le demande parce que l'application hébergée dotnet.exe fonctionne bien avec une grande quantité de données (> 5 Go) alors que la même chose avec w3wp.exe échoue sur 2,6 Go avec AccessViolation .
Mise à jour: mon application fonctionne sur un pool non géré tandis que dotnet.exe utilise .NET 4 .
3 Réponses :
dotnet.exe indique qu'il est hébergé sur le serveur Web par défaut Kestrel et non sur IIS w3wp.exe . Kestrel est l'environnement d'hébergement par défaut (hébergement interne). Vérifiez votre fichier LaunchSetting.json et vous avez surtout configuré IIS pour qu'il soit utilisé pour l'hébergement de votre application
Ce dont vous parlez vraiment, ce sont deux choses différentes. Tout d'abord, vous avez le concept de l'exécution avec un serveur Web comme IIS plutôt que via Kestrel directement. Ensuite, il y a le concept de l'exécution dans IIS comme dans proc ou hors de proc.
Prenons le premier. Chaque fois que vous exécutez quelque chose dans IIS, vous obtenez le processus w3wp.exe (ou plusieurs s'il est exécuté via une batterie de serveurs Web). Cela n'a vraiment rien à voir avec .NET Core, c'est juste le processus pour le pool d'applications dans IIS. Vous pouvez également choisir d'exécuter simplement votre application directement avec dotnet.exe (Kestrel), ce qui entraîne bien sûr l'exécution de ce processus.
Ensuite, si vous hébergez dans IIS, vous pouvez exécuter proc ou out. En l'absence de processus, l'ancien mode par défaut (en fait l'ancien seul moyen), IIS sert de proxy inverse - le pool d'applications (w3wp.exe) envoie les requêtes proxy au processus d'application réel exécuté via Kestrel (dotnet.exe). Dans ce scénario, les deux processus sont présents, car les deux sont utilisés. ASP.NET Core 2.2 a introduit un nouveau modèle d'hébergement: en cours, où l'application ASP.NET Core s'exécute directement dans le pool d'applications, il en résulte uniquement w3wp.exe.
En bref, la présence ou l'absence de ces processus dépend de ce que vous faites. Si vous utilisez IIS sous quelque forme que ce soit, w3wp.exe est inévitable.
FWIW, "w3wp" est un acryonyme pour "World Wide Web Worker Process". Cela rend probablement un peu plus évident pourquoi il est omniprésent dans les scénarios d'hébergement IIS: c'est littéralement le processus de travail qui gère les requêtes Web.
Quant à votre problème plus spécifique, qui revient essentiellement à manquer de mémoire, cela n'a vraiment rien à voir avec autre chose que la façon dont la mémoire est allouée. Un seuil de 2,6 Go crie 32 bits: il y a une allocation maximale de 4 Go, dont une partie est consacrée à la surcharge du processus. Cependant, il n'y a aucune raison pour que vous deviez exécuter 32 bits. Si votre pool d'applications fonctionne en 64 bits, vous pouvez théoriquement accéder à plus de mémoire que vous n'en auriez jamais besoin. En bref, il n'y a rien d'inhérent à IIS ou au processus w3wp.exe qui vous verrouille à seulement 2,6 Go de mémoire allouable. Il doit y avoir autre chose en jeu.
dotnet.exe est le nom du processus de travail du serveur Kestrel. Il s'agit d'un serveur Web interne inclus par défaut dans l'application .netcoreweb. Lorsque l'application .netcore est en cours d'exécution sur le serveur kertrel, dotnet.exe traite la demande entrante.
w3wp.ex est le nom du processus de travail du serveur Web IIS. Lorsque l'application est en cours d'exécution sur le serveur IIS, w3wp.exe traite la demande entrante.