est-il réaliste d'utiliser la classe C # .NET HTTplistener comme Fondation pour un serveur Web de calibre de production?
Le service Web HTTP que j'ai besoin d'héberger contient no .aspx ou fichiers statiques. Toutes les réponses HTTP sont dynamiques et générées dans le code C # invoquées via quelques instructions de commutation qui inspectent un format de l'URL reposant.
Ma pensée est que l'IIS est vraiment un wrapper en mode utilisateur autour du module de noyau Windows O / S HTTP-SYS qui effectue toute la manipulation du réseau intensif et le HTTplistener.
J'ai déjà un serveur Web multithreadisé de base qui fonctionne excellent pour le développement, car il commence au mode de débogage dans une instance, je pense que j'ai besoin de la surkillée de l'IIS pour la production. Une faible empreinte mémoire est une autre attraction.
4 Réponses :
Si vous l'écrivez, vous devrez le maintenir. Microsoft a déjà écrit un serveur Web - vous devez l'utiliser.
La consommation de mémoire est une bonne raison de ne pas utiliser IIS. La dernière fois que je l'ai utilisé dans la colère, nous avons dû activer le commutateur de 3 Go de donner une hauteur poussette de mémoire IIS plus de 1,7 Go. Faites les mathématiques d'hébergement sur une plate-forme cloud et vous verrez le problème de $$$.
Je vous suggère fortement d'essayer IIS 7 et voyez si cela reste un problème. Cela peut également avoir été dû à l'application spécifique et non à IIS.
@Js "Je vous suggère fortement d'essayer IIS 7 et voyez si cela reste un problème." Ok va faire, je suis sur bizspark maintenant afin que je puisse reposer quelques outils de test MS pour un test de tampon de mémoire. Un gotcha, la plate-forme Amazon Cloud est bloquée sur Windows 2003 pour le moment ... ho hmm.
Vous avez deux choix sérieux ici. Et non, codage de votre propre serveur Web avec HTTplistener n'est pas de qualité de production.
1) Utilisez IIS. Il a une tonne de fonctionnalités pour la sécurité, la performance et peut-être plus important encore, la gestion de la gestion que vous devriez vous réinventer. Comme une administration à distance, une journalisation, une sécurité Windows intégrée, etc.
2) Utilisez WCF et créez un service de service pour héberger vos fichiers. Ensuite, vous devrez mettre en œuvre vos propres services et trouver un moyen de gérer leur vie. Vous pouvez le faire, mais encore une fois, si vous parlez des appels Web reposants, IIS est vraiment la voie à suivre.
Rouler manuellement le vôtre devrait être évité. IIS a beaucoup changé au cours des 10 dernières années. C'est en aucun cas un grand serveur monolithique. Ils ont modélisé à peu près tout, en particulier dans Windows 2008, vous obtenez donc un système maigre et rapide.
@Dave Markle - Merci, je dois lire les améliorations de l'IIS, mes connaissances bloquées à Windows 2003. Lean et le Fast est ce dont j'ai besoin.
@Dave markle - pas d'administrateur distant = bon trou de sécurité de configuration. Pas de journalisation = Aucun problème, avec des services Web dynamiques Une grande partie de la nature de la demande est enterré dans les données de poste afin que les journaux ne s'exposent pas beaucoup pour le diagnostic. Pas de sécurité intégrée = bon, n'en avez pas besoin de même une chose de moins à malfigurer.
Vous jugez par les normes de Windows Server 2003. 2008-2003 = 5 ans de différence. La journalisation est bien meilleure, ne se limite pas aux une-doublures du journal IIS et comprend une journalisation détaillée de la demande échouée.
Eh bien, comme on l'a dit - essayez d'utiliser IIS au début.
HTTplistener n'est pas mauvais du tout - c'est le serveur d'écoute géré le plus rapide que vous puissiez avoir maintenant (plus rapide que TCplistener et plus rapide que la classe Socket). Et c'est en fait le même noyau qu'avec IIS. Mais IIS a beaucoup de choses plus.
Je ne peux pas dire que l'IIS est monolithique - l'usage d'hébergement montrant qu'il est devenu pire dans Win2008 en termes de stabilité et de gestion. Mais votre solution fabriquée à la main peut être bien pire. Et n'oubliez pas non plus - http.sys beaucoup plus personnalisable que HTTplistener. C'est à dire. Vous ne pouvez pas faire en streaming avec HTTPlistener, mais vous pouvez le faire avec http.sys - Question À propos de HTTplistener Streaming
Mais si vous aurez suffisamment de pouvoir en tant que développeur, vous pouvez essayer d'écrire votre propre wrapper http.sys et c'est la meilleure approche de l'écriture de son serveur Web propre dans Windows.
Avez-vous une URL qui détaille comment Win2008 a diminué dans la stabilité et la gestion?
déchets, roulez le vôtre. L'architecture le permet. Sachez s'il existe des comportements étranges dans la classe. La fermer à quelques reprises dans un service NT le rend fondu comme un sac de pâtisseries feuilletées.
Si vous l'exécutez sur la console, aucun problème, que ce soit, exécutez-le ASYNC et tout devrait être bien, cependant, démarrer et arrêter la chose de la Darn. C'est un problème différent que je me passe actuellement en difficulté, car aucune erreur n'est produite à partir des classes scellées hermétiquement microsoft.
Je ressens python à venir avec un petit tireau de cerisier
BTW, c'est la classe .NET
httplistener , pas le "C # .NET ClasseHTTplistener ". Tout dans .NET peut être utilisé par chaque langue, pas seulement C #.@John Saunders - J'essayais de préciser que ma question n'était pas sur une classe Java du même nom, j'ai évidemment essayé trop fort.
Je n'utiliserais pas httplistener, ce n'est pas le plus grand wrapper pour httpapi.dll, vous pouvez écrire votre propre wrapper, ou si vous êtes vraiment fou, vous pouvez en construire un à partir de TCplistener. Quelqu'un travaillant déjà sur ce: WebServer.codeplex.com