visual unity studio net actualizar c# linux mono servicestack mod-fastcgi

c# - studio - monodevelop unity 2018



¿Cuál es la mejor manera de ejecutar ServiceStack en Linux/Mono? (5)

Incluido en el sitio web de ServiceStack , muestra que ServiceStack puede ejecutarse en Mono con cualquiera de los dos:

  • XSP
  • mod_mono
  • FastCgi
  • Consola

¿Cuáles son estas configuraciones diferentes y cuál es la preferida para los servicios web en Mono?

Actualización para Linux

Desde la versión v4.5.2, ServiceStack ahora es compatible con .NET Core, que ofrece mejoras significativas en el rendimiento y la estabilidad de Mono que se derivan de una base de código multiplataforma compartida y son compatibles con el equipo de Microsoft con recursos, activo y sensible. Si actualmente está ejecutando ServiceStack en Mono, le recomendamos encarecidamente que actualice a .NET Core para aprovechar su rendimiento superior, su estabilidad y su pila de tecnología compatible de arriba a abajo.

Actualización para mono

Nuestra configuración recomendada para alojar sitios ASP .NET en Linux y Mono es usar nginx / HyperFastCgi. Hemos publicado una guía paso a paso a través de la creación de una máquina virtual de Ubuntu desde cero completa con los scripts de despliegue / install / conf / init en mono-server-config .

Ya no recomendamos MonoFastCGI después de notar varios problemas de estabilidad y rendimiento. Esta publicación del blog proporciona un buen análisis del rendimiento, el uso de la memoria y la estabilidad de las diferentes opciones de Alojamiento ASP.NET en Mono .

Desarrollo

XSP es similar al servidor VS.NET WebDev: un servidor web ASP.NET autónomo y simple escrito en C #. Esto es adecuado para el desarrollo o pequeñas cargas de trabajo. Simplemente ejecútelo desde el directorio raíz de su servidor de ServiceStack ASP.NET que lo hará disponible en http://localhost:8080 .

Producción

Para servicios de Internet externos, generalmente desea hospedar servicios web de ServiceStack como parte de un servidor web con todas las funciones. Los 2 servidores web más populares para Linux son:

Nginx

Use Mono FastCGI para hospedar hosts de ServiceStack ASP.NET en Nginx .

apache

Use mod_mono para alojar hosts de ServiceStack ASP.NET en un servidor HTTP Apache .

Alojamiento propio

ServiceStack también admite el hospedaje automático, que le permite ejecutar sus servicios web ServiceStack de forma independiente en una aplicación de consola independiente (es decir, sin un servidor web). Esta es una buena idea cuando no necesita los servicios de un servidor web con todas las funciones (por ejemplo, solo necesita alojar servicios web internamente en una Intranet).

Por defecto, el mismo binario de la aplicación ServiceStack Console se ejecuta tanto en Windows / .NET como en Mono / Linux tal cual. Aunque si lo desea, puede demonizar fácilmente su aplicación para que se ejecute como un demonio de Linux como se describe aquí . La página wiki también incluye instrucciones para configurar su servicio web auto-hospedado para ejecutarse detrás de un proxy inverso Nginx o Apache.

Dado que proporciona una buena adaptación al modelo de concurrencia de Heroku, tal como se detalla en su aplicación de 12 factores , el alojamiento en sí mismo será un área en la que buscaremos brindar un mayor soporte en un futuro cercano.

ServiceStack.net Nginx / Mono FastCGI configuración

El propio sitio web servicestack.net (incluyendo todas las demostraciones en vivo) se ejecuta en un servidor virtual Ubuntu usando Nginx + Mono FastCGI.

Este comando se utiliza para iniciar el proceso en segundo plano 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 &

Que alberga todas las aplicaciones definidas en los archivos * .webapp en la carpeta /etc/rc.d/init.d/mono-fastcgi especificada mediante el formato de archivo de aplicación web de XSP , por ejemplo:

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>

Esto ejecuta el proceso FastCGI Mono en segundo plano, al que puede hacer que se conecte Nginx agregando esta regla a nginx.conf:

location ~ /(ServiceStack|RedisAdminUI|Redis|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; }

Lo que reenviará cualquier ruta que comience con /ServiceStack o /RedisAdminUI , etc. al proceso del servidor mono FastCGI para su procesamiento. Algunas aplicaciones de ejemplo alojadas de esta manera:

Para aquellos interesados, los archivos de configuración completos de Nginx + FastCGI para servicestack.net están disponibles para descargar .

Descargo de responsabilidad: soy el autor del servidor HyperFastCgi y el autor de la publicación del blog se mencionó en la respuesta de ceco

nginx con HyperFastCgi hace este trabajo. HyperFastCgi no pierde memoria como servidor mono fastcgi y se realiza mucho más rápido, ya que utiliza la API mono de bajo nivel para pasar datos entre dominios de aplicación en lugar de una implementación JIT mono lenta de llamadas entre dominios. También tiene la opción de usar la biblioteca libevent nativa para las comunicaciones de sockets, que es aproximadamente 1.5-2 más rápida que la implementación mono actual de System.Net.Sockets.

Características clave de HyperFastCgi:

  • Permite utilizar 3 formas diferentes de lidiar con sockets y comunicación entre dominios:
    • Managed Listener with Managed Transport (utiliza solo código administrado, System.Net.Sockets asíncronos. Lento en mono, debido a las lentas llamadas entre dominios JIT)
    • Managed Listener with Combined Transport (usa Async System.Net.Sockets como oyente y mono API de bajo nivel para llamadas entre dominios. Mucho más rápido)
    • Native Listener (utiliza libevent nativo como biblioteca de sockets y API mono de bajo nivel para realizar llamadas entre dominios. El mejor rendimiento)
  • Permite varias formas de realizar solicitudes web en paralelo: mediante ThreadPool, .NET 4.5 Task o Single-threading. Las últimas opciones se combinan con Native Listener que el servidor web funcione como NodeJS : todas las solicitudes se procesan en un solo hilo de forma asíncrona.
  • Permite escribir manejadores de solicitudes simples sin usar System.Web en absoluto. Esto aumenta el rendimiento de procesamiento de las solicitudes de 2-2.5 veces.

Hay una publicación de blog útil y relativamente reciente sobre el rendimiento de Mono usando ServiceStack. Pensé que podría ser de utilidad para algunos que están a punto de decidir cómo alojar sus servicios: Rendimiento de Servicestack en Mono .

Como dice, el servidor FastCGI Mono tiene toneladas de pérdidas de memoria que puedo confirmar. ab -n 100000 -c 10 http://myurl en Ubuntu Desktop 14.04 con Mono 3.2.8 y Nginx 1.4.6 y FastCGI Mono Server 3.0.11 y un servicio escrito con ServiceStack 3.9.71. No creo que importe qué versión de ServiceStack estoy usando ya que el FastCGI Mono Server es el bit con fugas. Se comió toda la memoria disponible, aproximadamente 1 Gb de 2 GB en total.

Además, el rendimiento de Nginx + FastCGI Mono Server es malo , al menos en comparación con otras soluciones. Mi servicio REST de muestra tenía aproximadamente 275 solicitudes por segundo. El autor del blog había revisado el código del FastCGI Mono Server y decidió escribir su propia implementación. Sin embargo, por alguna razón no funciona, al menos en mi máquina.

Entonces, el punto, supongo, es que no debes usar el FastCGI Mono Server. A menos que desee reiniciar su caja a menudo.

Como esta publicación es en su mayoría negativa, debería decir cuáles son mis intenciones con respecto a hospedar mis servicios. Probablemente optaré por un alojamiento propio con un AppHost que herede AppHostHttpListenerLongRunningBase detrás de Nginx. Al usar el mismo servicio REST de muestra anterior, obtengo aproximadamente 1100 solicitudes por segundo. La mejor noticia es que el proceso no tuvo fugas aparentes, lo probé con aproximadamente 1 000 000 de solicitudes y el proceso consumió <100 MB de RAM.

PD No soy el autor de la entrada del blog :)

En producción usamos nginx con sockets de archivos unix.

Encontramos una fuga de errores / memoria al usar comunicación de socket con nginx, service stack y mono. Esto fue con 500 solicitudes simultáneas, mientras que usted esperaría un aumento en la CPU y la memoria, nunca volvió a bajar. No hicimos más pruebas para descubrir dónde estaba el problema, pero hay un error registrado con xamarin bugzilla que parece similar a los problemas que tuvimos. Esencialmente probamos lo siguiente y fue lo suficientemente bueno para nosotros.

Pasamos a usar sockets de Unix con los siguientes parámetros de comando

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

El problema que tuvimos con este método es que los permisos del archivo de socket cambiaron cada vez que ejecutas fastcgi-mono-server4, por lo que debes corregirlos después de haber iniciado fastcgi-mono-server4. El otro inconveniente es que en nuestras casillas solo podía manejar unas 120 solicitudes simultáneas. Sin embargo, esto no es realmente un problema para nosotros en este momento y siempre puede generar más procesos.

Espero que esto ayude