web-dev-qa-db-fra.com

Quelle est la meilleure façon d'exécuter ServiceStack sur Linux / Mono?

Listé sur le site Web ServiceStack il montre que ServiceStack peut fonctionner sur Mono avec:

  • XSP
  • mod_mono
  • FastCgi
  • Console

Quelles sont ces différentes configurations et laquelle est préférée pour les services Web en mono?

c#linuxmonoservicestackmod-fastcgi
48
mythz

Mise à jour pour Linux

De 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é d'une base de code multiplateforme partagée et pris en charge par Microsoft disposant de nombreuses ressources, actif et réactif équipe. Si vous exécutez actuellement ServiceStack sur Mono, nous vous recommandons vivement de mettre à niveau vers .NET Core pour profiter de ses performances supérieures, de sa stabilité et de sa pile technologique prise en charge de haut en bas.

Mise à jour pour Mono

Notre configuration recommandée pour l'hébergement ASP .NET sites sur Linux et Mono consiste à utiliser nginx/HyperFastCgi. Nous avons publié un guide étape par étape lors de la création d'un Ubuntu VM à 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 performances. Ce billet de blog fournit une bonne analyse des performances, de l'utilisation de la mémoire et de la stabilité de différentes options d'hébergement ASP.NET en mono .

Développement

XSP est similaire au serveur VS.NET WebDev - un simple serveur Web ASP.NET autonome écrit en C #. Cela convient au développement ou aux petites charges de travail. Vous venez de l'exécuter à partir du répertoire racine de votre hôte ServiceStack ASP.NET qui le rendra disponible à http://localhost:8080.

Production

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

Nginx

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

Apache

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

Auto-hébergement

ServiceStack prend également en charge l'auto-hébergement qui vous permet d'exécuter vos services Web ServiceStack seul dans une application console autonome (c'est-à-dire 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, le même binaire de l'application Console ServiceStack s'exécute tel quel sur Windows/.NET et Mono/Linux. Bien que si vous le souhaitez, vous pouvez facilement démonifier votre application pour exécuter en tant que démon Linux comme indiqué ici . La page wiki comprend également des instructions pour configurer votre service Web auto-hébergé pour qu'il s'exécute derrière un proxy inverse Nginx ou Apache.

Puisqu'il fournit un bon ajustement pour le modèle de concurrence de Heroku comme détaillé dans leur application à 12 facteurs l'auto-hébergement sera un domaine que nous chercherons à fournir un support accru dans un avenir proche.

Configuration ServiceStack.net Nginx/Mono FastCGI

Le site Web servicestack.net lui-même (y compris toutes les démos en direct) fonctionne sur un buntu hetzner vServer 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 dans le /etc/rc.d/init.d/mono-fastcgi dossier spécifié à l'aide de XSP's WebApp File Format , par exemple:

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 exécute le processus FastCGI Mono en arrière-plan auquel vous pouvez obtenir Nginx pour 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 du serveur mono FastCGI pour le traitement. Quelques exemples d'applications hébergées de cette façon:

Pour ceux qui sont intéressés, les fichiers de configuration Nginx + FastCGI complets pour servicestack.net sont disponibles en téléchargement .

83
mythz

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 de socket avec nginx, la pile de service et le mono. C'était avec 500 demandes simultanées, alors que vous vous attendez à un pic de CPU et de mémoire, il n'est jamais revenu. Nous n'avons pas fait d'autres tests pour découvrir où était le problème, mais il y a un bogue enregistré avec xamarin bugzilla qui semble similaire aux problèmes que nous avons rencontrés. Essentiellement, nous avons essayé ce qui suit et c'était assez bon pour nous.

Nous sommes passés à l'utilisation de sockets unix avec les paramètres 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 autorisations du fichier socket changent à 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îtiers, il ne pouvait traiter qu'environ 120 demandes simultanées. Cependant, ce n'est pas vraiment un problème pour nous pour le moment et vous pouvez toujours générer plus de processus.

J'espère que cela t'aides

19
Antony Denyer

Avertissement: je suis l'auteur du serveur HyperFastCgi et l'auteur de l'article de blog a été mentionné dans la réponse de ceco

nginx avec HyperFastCgi faites 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 des données entre les domaines d'application au lieu de l'implémentation JIT mono lente des appels interdomaines. Il a également la possibilité d'utiliser la bibliothèque native libevent pour les communications de sockets, qui est environ 1,5-2 plus rapide que l'implémentation mono System.Net.Sockets mono actuelle.

Caractéristiques clés d'HyperFastCgi:

  • Permet d'utiliser 3 façons 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 asynchrones. Lent en mono, en raison des appels inter-domaines JIT lents)
    • Managed Listener with Combined Transport (utilise async System.Net.Sockets comme écouteur et API mono de bas niveau pour les appels interdomaines. Beaucoup plus rapide)
    • Native Listener (utilise natif libevent comme bibliothèque de sockets et API mono de bas niveau pour effectuer des appels interdomaines. Les meilleures performances)
  • Permet plusieurs façons de mettre en parallèle des requêtes Web: en utilisant ThreadPool, .NET 4.5 Task ou Single-threading. La dernière option est combinée avec Native Listener fait fonctionner le serveur web comme NodeJS: toutes les requêtes sont traitées en un seul thread de manière asynchrone.
  • Permet d'écrire de simples gestionnaires de requêtes sans utiliser System.Web du tout. Cela augmente les performances de traitement des demandes de 2 à 2,5 fois.
6
Sergey Zhukov

Il existe un article de blog utile et relativement récent concernant les performances de Mono avec ServiceStack. J'ai pensé que cela pourrait être utile à certains qui sont sur le point de décider comment héberger leurs services: Performances de la pile de services en mono.

Comme il est dit - le serveur FastCGI Mono a tonnes de fuites de mémoire que je peux confirmer. J'ai couru 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 ne pense pas que la version de ServiceStack que j'utilise importe, car le serveur FastCGI Mono est le bit qui fuit. Il a mangé toute la mémoire disponible - environ 1 Go sur 2 Go au total.

De plus, les performances de Nginx + FastCGI Mono Server sont mauvaises , du moins par rapport à d'autres solutions. Mon échantillon REST avait environ 275 requêtes par seconde. L'auteur du blog avait examiné le code de FastCGI Mono Server et décidé d'écrire sa propre implémentation. Pour une raison quelconque, cela ne fonctionne pas cependant, à moins sur ma machine.

Donc, le point, je suppose, est que vous ne devez pas utiliser le serveur mono FastCGI. A moins que vous ne souhaitiez redémarrer votre box souvent.

Comme ce message est principalement négatif, je dois 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 de AppHostHttpListenerLongRunningBase derrière Nginx. En utilisant le même échantillon REST ci-dessus, j'obtiens environ 1100 requêtes par seconde. La meilleure nouvelle est que le processus n'a pas présenté de fuite apparente, je l'ai testé avec environ 1 000 000 de requêtes et le processus avait consommé <100 Mo de RAM.

P.S. Je ne suis pas l'auteur du billet de blog :)

3
ceco

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
2
mikowiec