Quelle est la meilleure façon de faire fonctionner ServiceStack sous Linux / Mono?

Mise à jour pour Linux

Depuis la version v4.5.2, ServiceStack prend désormais en charge .NET Core, qui offre des améliorations significatives en termes de performances et de stabilité par rapport à Mono, dérivées d’un code partagé multiplate-forme et supscopes par une équipe active, réactive et dotée de ressources. Si vous exécutez actuellement ServiceStack sur Mono, nous vous recommandons vivement de mettre à niveau vers .NET Core pour tirer parti de ses performances, de sa stabilité et de sa technologie Stack.

Mise à jour pour Mono

Notre configuration recommandée pour héberger des sites ASP .NET sous Linux et Mono consiste à utiliser nginx / HyperFastCgi. Nous avons publié un guide pas à pas sur la création d’une machine virtuelle Ubuntu à partir de zéro avec des scripts deploy / install / conf / init sur mono-server-config .

Nous ne recommandons plus MonoFastCGI après avoir remarqué plusieurs problèmes de stabilité et de performance. Cet article de blog fournit une bonne parsing des performances, de l’utilisation de la mémoire et de la stabilité des différentes options d’hébergement ASP.NET dans Mono .

Développement

XSP est similaire au serveur WebDev VS.NET – un simple serveur Web ASP.NET autonome écrit en C #. Ceci est adapté pour le développement ou de petites charges de travail. Il vous suffit de l’exécuter à partir du répertoire racine de votre hôte ASP.NET ServiceStack qui le rendra disponible à l’ http://localhost:8080 .

Production

Pour les services Internet externes, vous souhaitez généralement héberger des services Web ServiceStack dans le cadre d’un serveur Web complet. Les deux serveurs Web les plus populaires pour Linux sont les suivants:

Nginx

Utilisez Mono FastCGI pour héberger les hôtes ServiceStack ASP.NET dans Nginx .

Apache

Utilisez mod_mono pour héberger des hôtes ServiceStack ASP.NET dans un serveur HTTP Apache .

Auto-hébergement

ServiceStack prend également en charge l’auto-hébergement, ce qui vous permet d’exécuter vos services Web ServiceStack dans une application console autonome (sans serveur Web). C’est une bonne idée lorsque vous n’avez pas besoin des services d’un serveur Web complet (par exemple, il vous suffit d’héberger des services Web en interne sur un intranet).

Par défaut, la même application binary ServiceStack Console s’exécute sur Windows / .NET et Mono / Linux tel quel. Bien que si vous le souhaitez, vous pouvez facilement démoniser votre application pour qu’elle fonctionne en tant que démon Linux, comme indiqué ici . La page wiki comprend également des instructions pour configurer votre service Web auto-hébergé afin qu’il s’exécute derrière un proxy inverse Nginx ou Apache.

Étant donné qu’il convient parfaitement au modèle de concurrence de Heroku, tel que détaillé dans leur application d’ auto-hébergement à 12 facteurs , nous chercherons à fournir une assistance accrue dans un avenir proche.

Configuration ServiceStack.net Nginx / Mono FastCGI

Le site Web de servicestack.net lui-même (y compris toutes les démos en direct) fonctionne sur un serveur Ubuntu hetzner utilisant Nginx + Mono FastCGI.

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

 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 héberge toutes les applications définies dans les fichiers * .webapp du dossier /etc/rc.d/init.d/mono-fastcgi spécifié à l’aide du format de fichier WebApp de XSP , par exemple:

ServiceStack.webapp:

   ServiceStack.Northwind * 80 /ServiceStack.Northwind /home/mythz/src/ServiceStack.Northwind   

Cela exécute le processus FastCGI Mono en arrière-plan auquel Nginx peut se connecter en ajoutant cette règle à 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 transmettra tout itinéraire commençant par /ServiceStack ou /RedisAdminUI , etc. au processus de serveur mono FastCGI pour le traitement. Quelques exemples d’applications hébergées de cette manière:

• 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 que cela intéresse, les fichiers de configuration complets de Nginx + FastCGI pour servicestack.net peuvent être téléchargés .

En production, nous utilisons nginx avec des sockets de fichiers unix

Nous avons trouvé une fuite de bogue / mémoire lors de l’utilisation de la communication par socket avec nginx, la stack de services et mono. C’était avec 500 demandes simultanées, alors que vous vous attendiez à un pic dans le processeur et à la mémoire, il n’est plus jamais redescendu. Nous n’avons pas effectué de tests supplémentaires pour découvrir où était le problème, mais un bogue enregistré avec xamarin bugzilla semble similaire aux problèmes rencontrés. Essentiellement, nous avons essayé ce qui suit et c’était assez bien pour nous.

Nous sums passés à l’utilisation des sockets Unix avec les parameters de commande suivants

fastcgi-mono-server4 /filename=/tmp/something.socket / socket = unix / applications = / var / www /

Le problème que nous avons rencontré avec cette méthode est que les permissions du fichier de socket sont modifiées chaque fois que vous exécutez fastcgi-mono-server4, vous devez donc les corriger après avoir démarré fastcgi-mono-server4! L’autre inconvénient est que sur nos boîtes, il ne pouvait traiter que 120 demandes simultanées. Cependant, ce n’est pas vraiment un problème pour nous en ce moment et vous pouvez toujours engendrer plus de processus.

J’espère que cela t’aides

Disclaimer: Je suis l’auteur du serveur HyperFastCgi et l’auteur du blog a été mentionné dans la réponse de ceco

nginx avec HyperFastCgi fait ce travail. HyperFastCgi ne fuit pas la mémoire en tant que serveur mono fastcgi et fonctionne beaucoup plus rapidement, car il utilise une API mono de bas niveau pour transmettre les données entre les domaines d’application au lieu d’une implémentation mono JIT lente des appels interdomaine. Il est également possible d’utiliser la bibliothèque libevent native pour les communications de sockets, qui est environ 1,5 à 2 fois plus rapide que l’implémentation mono System.Net.Sockets actuelle.

Principales caractéristiques de HyperFastCgi:

• Permet d’utiliser trois manières différentes de gérer les sockets et la communication entre domaines:
  • Managed Listener with Managed Transport (utilise uniquement du code managé, System.Net.Sockets asynchrone. Ralenti en mono, en raison des appels inter-domaines JIT lents)
  • Écouteur Managed Listener with Combined Transport (utilise asynchrone System.Net.Sockets comme écouteur et API mono de bas niveau pour les appels entre domaines)
  • Native Listener (utilise libevent natif comme bibliothèque de sockets et API mono de bas niveau pour effectuer des appels interdomaines )
• Permet plusieurs manières de mettre en parallèle des requêtes Web: en utilisant ThreadPool, .NET 4.5 Task ou Single-threading. Les dernières options sont combinées avec Native Listener fait que le serveur Web fonctionne comme NodeJS : toutes les requêtes sont traitées en un seul thread de manière asynchrone.
• Permet d’écrire des gestionnaires de requêtes simples sans utiliser System.Web. Cela augmente les performances de traitement des demandes 2 à 2,5 fois.

Il y a un billet de blog utile et relativement récent concernant les performances de Mono à l’aide de ServiceStack. Je pensais que cela pourrait être utile à ceux qui sont sur le sharepoint décider comment héberger leurs services: les performances de Servicestack dans Mono .

Comme il est dit – le serveur FastCGI Mono a des tonnes de memory leaks que je peux confirmer. J’ai exécuté ab -n 100000 -c 10 http://myurl sur Ubuntu Desktop 14.04 en utilisant Mono 3.2.8 et Nginx 1.4.6 et FastCGI Mono Server 3.0.11 et un service écrit en utilisant ServiceStack 3.9.71. Je pense que peu importe la version de ServiceStack que j’utilise depuis que le FastCGI Mono Server est le bit qui fuit. Il a mangé toute la mémoire disponible – environ 1 Go sur 2 Go au total.

En outre, les performances de Nginx + FastCGI Mono Server sont mauvaises , du moins par rapport aux autres solutions. Mon exemple de service REST comportait environ 275 requêtes par seconde. L’auteur du blog avait revu le code de FastCGI Mono Server et décidé de rédiger sa propre implémentation. Pour une raison quelconque, cela ne marche pas, du moins sur ma machine.

Donc, le point, je suppose, est que vous ne devriez pas utiliser le FastCGI Mono Server. Sauf si vous souhaitez redémarrer votre boîte souvent.

Comme cet article est principalement négatif, je devrais dire quelles sont mes intentions concernant l’hébergement de mes services. Je vais probablement opter pour l’auto-hébergement avec un AppHost héritant d’ AppHostHttpListenerLongRunningBase derrière Nginx. En utilisant le même exemple de service REST ci-dessus, je reçois environ 1100 requêtes par seconde. La meilleure nouvelle est que le processus n’a pas eu de fuites apparentes, je l’ai testé avec environ 1 000 000 de requêtes et le processus avait consommé moins de 100 Mo de RAM.

PS Je ne suis pas l’auteur du billet de blog 🙂

evhttp-sharp – Serveur http avec hôte pour NancyFx

https://github.com/kekekeks/evhttp-sharp

Très rapide, presque 4 fois plus rapide que nancy-libevent2.

http://www.techempower.com/benchmarks/#section=data-r8&hw=i7&test=json&s=2&l=2

Il existe des résultats de test pour différentes configurations:

Réponses JSON par seconde:

• evhttp-sharp 91,557
• nancy-libevent2 17,338
• servicestack-nginx-d 953
• Nancy 896
• aspnet-jsonnet-mono 863