Quel est le meilleur moyen d’exécuter ServiceStack sous Linux / Mono?

Question

Figurant sur la ServiceStack site web , il montre que la ServiceStack peut s'exécuter sur Mono avec soit:

• XSP
• mod_mono
• FastCgi
• Console

Ce sont ces différentes configurations et qui est préféré pour les Services Web sur Mono?

Answer 1

Développement

XSP est similaire à VS.NET WebDev server - une simple autonome ASP.NET Serveur web écrit en C#. Ceci est approprié pour le développement ou les petites charges de travail. Vous venez de le lancer depuis le répertoire racine de votre ServiceStack ASP.NET l'hôte, ce qui va rendre disponible à l' http://localhost:8080.

La Production

Pour les externes, les services de l'internet en général, vous voulez héberger ServiceStack services web dans le cadre d'un Serveur de Web complet. Les 2 plus populaires de web complet serveurs pour Linux sont:

Nginx

Utilisation Mono FastCGI pour accueillir ServiceStack ASP.NET les hôtes de Nginx.

Apache

Utilisation mod_mono pour accueillir ServiceStack ASP.NET les hôtes dans un Serveur HTTP Apache.

Auto Hébergement

ServiceStack prend également en charge l'auto-hébergement qui vous permet d'exécuter votre ServiceStack webservices sur son propre dans un standalone application Console (c'est à dire sans un serveur web). C'est une bonne idée lorsque vous n'avez pas besoin des services d'un serveur de web complet (e.g: vous avez juste besoin d'héberger des services web en interne sur un Intranet).

Par défaut, le même ServiceStack application Console binaire fonctionne aussi bien sur Windows/.NET et Mono/Linux-est. Bien que si vous le souhaitez, vous pouvez facilement daemonize votre application à exécuter en tant que daemon Linux. comme indiqué ici. La page wiki comprend également des instructions pour la configuration de votre auto-hébergé service web de courir derrière un Nginx ou Apache en reverse proxy.

Car il offre un bon ajustement pour Heroku de Simultanéité de modèle comme détaillé dans leurs 12 facteur d'application de l'auto-hébergement sera une zone que nous allons être à la recherche afin de fournir plus de soutien autour de dans un avenir proche.

ServiceStack.net Nginx / Mono configuration FastCGI

L'servicestack.net site web lui-même (inc. toutes les démonstrations en direct) fonctionne sur un Ubuntu hetzner vServer l'aide de Nginx + Mono FastCGI.

Cette commande est utilisée pour démarrer le FastCGI processus d'arrière-plan:

fastcgi-mono-server4 --appconfigdir /etc/rc.d/init.d/mono-fastcgi 
  /socket=tcp:127.0.0.1:9000 /logfile=/var/log/mono/fastcgi.log &

Qui accueille toutes les applications définies dans *.webapp fichiers dans l' /etc/rc.d/init.d/mono-fastcgi dossier spécifié à l'aide XSP la WebApp Format de Fichier, e.g:

ServiceStack.webapp:

<apps>
<web-application>
        <name>ServiceStack.Northwind</name>
        <vhost>*</vhost>
        <vport>80</vport>
        <vpath>/ServiceStack.Northwind</vpath>
        <path>/home/mythz/src/ServiceStack.Northwind</path>
</web-application>
</apps>

Cela va à l'FastCGI Mono processus en arrière-plan, vous pouvez obtenir Nginx pour se connecter par l'ajout de cette règle de nginx.conf:

location ~ /(ServiceStack|RedisAdminUI|RedisStackOverflow|RestFiles)\.* {  
   root /usr/share/nginx/mono/servicestack.net/;  
   index index.html index.htm index.aspx default.htm Default.htm;  
   fastcgi_index /default.htm;
   fastcgi_pass 127.0.0.1:9000;  
   fastcgi_param SCRIPT_FILENAME /usr/share/servicestack.net$fastcgi_script_name;
   include /etc/nginx/fastcgi_params;  
}

Qui va de l'avant toute la route en commençant par /ServiceStack ou /RedisAdminUI, etc, à la FastCGI mono processus de serveur pour traitement. Quelques exemples d'applications hébergées de cette façon:

• http://www.servicestack.net/ServiceStack.Northwind/
• http://www.servicestack.net/ServiceStack.Hello/
• http://www.servicestack.net/RedisAdminUI/AjaxClient/
• http://www.servicestack.net/RedisStackOverflow/

Pour ceux qui s'intéressent à la pleine Nginx + FastCGI fichiers de configuration pour servicestack.net sont disponibles pour le téléchargement.

Answer 2

Dans la production, nous utilisons nginx avec de fichiers unix sockets

Nous avons trouvé un bug/fuite de mémoire lors de l'utilisation de socket de communication avec nginx, service de la pile et mono. Ce fut avec 500 demandes simultanées, tandis que vous vous attendez à un pic de l'uc et de mémoire il n'est jamais venu vers le bas encore. Nous n'avons pas fait d'autres essais pour découvrir où était le problème, mais il y a un bug connecté avec xamarin bugzilla qui semble similaire pour les questions que nous avions. Essentiellement, nous avons essayé le suivant et il était assez bon pour nous.

Nous sommes passés à l'aide de sockets unix avec la commande suivante params

fastcgi-mono-server4 /filename=/tmp/quelque chose.femelle /femelle=unix les applications /=/var/www/

Le problème que nous avons eu avec cette méthode est que les permissions du fichier de socket changé chaque fois que vous exécutez fastcgi-mono-server4 de sorte que vous avez à les corriger après que vous avez commencé à fastcgi-mono-server4! L'autre inconvénient, c'est que sur nos boîtes on ne pouvait traiter environ 120 demandes simultanées. Cependant ce n'est pas vraiment un problème pour nous en ce moment et vous pouvez toujours générer davantage de processus.

Espérons que cette aide

Answer 3

nginx avec HyperFastCgi faire ce travail. HyperFastCgi n'est pas une fuite de mémoire en tant que mono serveur fastcgi et effectue beaucoup plus rapide, car il utilise des bas-mono API pour transmettre des données entre des domaines d'application au lieu de ralentir mono JIT mise en œuvre de la croix-domaine d'appels. Il a aussi l'option d'utiliser natif de libevent bibliothèque pour les prises de communication qui est à environ 1,5-2 plus rapide que l'actuel Système mono.Net.Mise en œuvre des Sockets.

Principales caractéristiques de HyperFastCgi:

• Permet d'utiliser de 3 façons différentes de traiter avec les sockets et les communications inter-domaines:
  • Managed Listener with Managed Transport (utilise uniquement le code managé, Système asynchrone.Net.Les Sockets. Lent en mono, en raison de la lenteur JIT inter-domaine d'appels)
  • Managed Listener with Combined Transport (utilise un Système asynchrone.Net.Les Sockets en tant qu'auditeur et de bas niveau de mono API pour la croix-domaine d'appels. Beaucoup beaucoup plus rapide)
  • Native Listener (utilise le natif de libevent en tant que bibliothèque de socket et de bas niveau de mono API pour faire de la croix-domaine d'appels. Les meilleures performances)
• Permet plusieurs façons de faire en parallèle des demandes web: à l'aide de pool de threads, .NET 4.5 Tâche ou un thread Unique. Dernières options est combiné avec d' Native Listener rend le serveur web fonctionne comme NodeJS: toutes les demandes sont traitées dans un seul thread de manière asynchrone.
• Permet d'écrire sur simple demande des gestionnaires sans l'aide de Système.Web à tous. Cela augmente les performances de traitement des demandes de 2-2.5 fois.

Answer 4

Il est utile et relativement récent billet de blog au sujet de la performance de Mono à l'aide de ServiceStack. J'ai pensé qu'il pourrait être utile à certains qui sont sur le point de décider comment héberger leurs services: Servicestack performance en Mono.

Comme il est dit - le FastCGI Mono serveur a des tonnes de fuites de mémoire qui je peux le confirmer. J'ai couru ab -n 100000 -c 10 http://myurl sur le Bureau Ubuntu 14.04 à l'aide de Mono 3.2.8 et Nginx 1.4.6 et FastCGI Mono Serveur 3.0.11 et un service écrite à l'aide de ServiceStack 3.9.71. Je ne pense pas que cela importe quelle version de ServiceStack j'utilise depuis le FastCGI Mono Serveur est la fuite de bits. Il a mangé toute la mémoire disponible - 1 go environ de 2 GO au total.

Aussi, la performance de Nginx + FastCGI Mono Serveur est mauvais, au moins par rapport à d'autres solutions. Mon exemple de service REST avait environ 275 demandes par seconde. L'auteur du blog a examiné le code de FastCGI Mono Serveur et a décidé d'écrire sa propre mise en œuvre. Pour une raison qu'il ne fonctionne pas bien, au moins sur ma machine.

De sorte que le point, je pense, c'est que vous ne devriez pas utiliser le FastCGI Mono Serveur. Sauf si vous voulez redémarrer votre box souvent.

Comme ce post est le plus souvent négative, je dois dire quelles sont mes intentions à l'égard de l'hébergement de mes services. Je vais probablement aller pour l'auto-hébergement avec une AppHost hériter AppHostHttpListenerLongRunningBase derrière Nginx. En utilisant le même échantillon de REPOS de service ci-dessus, je reçois environ 1100 requêtes par seconde. La meilleure nouvelle est que le processus avait apparemment pas de fuites, je l'ai testé avec environ 1 000 000 de demandes et le processus avaient consommé de l' < 100 MO de RAM.

P. S. je ne suis pas l'auteur de l'article du blog :)