在Linux / Mono上运行ServiceStack的最佳方式是什么?

在ServiceStack网站上列出,它显示了ServiceStack可以在Mono上运行:

  • XSP
  • 是mod_mono
  • FASTCGI
  • 安慰

什么是这些不同的configuration,哪些是Mononetworking服务的首选?

Linux更新

从v4.5.2版本开始, ServiceStack现在支持.NET Core,它提供了比Mono更高的性能和稳定性改进,这源于共享的跨平台代码库,并得到了微软资源充足,积极响应的团队的支持。 如果您目前在Mono上运行ServiceStack,我们强烈build议升级到.NET Core,以利用其优越的性能,稳定性和从上到下支持的技术堆栈。

单声道更新

我们推荐的在Linux和Mono上托pipeASP .NET站点的安装程序是使用nginx / HyperFastCgi。 我们已经发布了一个分步指南,通过在mono-server-config上完成部署/安装/ conf / init脚本,从头开始创buildUbuntu VM。

注意到几个稳定性和性能问题后,我们不再推荐MonoFastCGI。 这篇博客文章提供了Mono中不同ASP.NET Hosting选项的性能,内存使用情况和稳定性的良好分析。


发展

XSP与VS.NET WebDev服务器类似 – 一个用C#编写的简单独立的ASP.NET WebServer。 这适用于开发或小工作量。 你只需从你的ServiceStack ASP.NET主机的根目录下运行它,它将使它在http://localhost:8080可用。

生产

对于外部Internet服务,您通常希望将ServiceStack Web服务作为全functionWeb服务器的一部分托pipe。 最受欢迎的2个全function的Linuxnetworking服务器是:

Nginx的

使用Mono FastCGI托pipeNginx中的 ServiceStack ASP.NET主机。

阿帕奇

使用mod_mono来托pipeApache HTTP服务器中的ServiceStack ASP.NET主机。

自我托pipe

ServiceStack还支持自托pipe,它允许您在独立的控制台应用程序(即没有Web服务器)中自行运行您的ServiceStack Web服务。 当您不需要全functionWeb服务器的服务时(例如:您只需要在Intranet上内部托pipeWeb服务),这是一个好主意。

默认情况下,相同的ServiceStack控制台应用程序二进制文件在Windows / .NET和Mono / Linux上运行。 虽然如果你愿意的话,你可以很容易地将你的应用程序作为一个Linux守护进程守护进程 。 维基页面还包含configuration自托pipeWeb服务以在Nginx或Apache反向代理后运行的说明。

因为它提供了Heroku的并发模型的一个很好的适合他们的12因子应用程序中详细的自我托pipe将是一个地区,我们将在不久的将来提供更多的支持。

ServiceStack.net Nginx / Mono FastCGIconfiguration

servicestack.net网站本身(包括所有现场演示)使用Nginx + Mono FastCGI在Ubuntu hetzner vServer上运行。

该命令用于启动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 & 

其中托pipe使用XSP的WebApp文件格式指定的/etc/rc.d/init.d/mono-fastcgi文件夹中* .webapp文件中定义的所有应用程序 ,例如:

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> 

这将在后台运行FastCGI Mono进程,通过将此规则添加到nginx.conf中,您可以获得Nginx连接的进程:

 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; } 

它将把任何以/ServiceStack/RedisAdminUI等开始的路由转发到FastCGI单声道服务器进程进行处理。 以这种方式托pipe的示例应用程序

对于那些感兴趣的完整的Nginx + FastCGIconfiguration文件的servicestack.net 可供下载 。

在生产中,我们使用nginx和unix文件套接字

当与nginx,服务堆栈和单声道使用套接字通信时,我们发现了一个bug /内存泄漏。 这是与500个并发请求,而你会期望在CPU和内存的高峰再也没有回落。 我们没有做任何进一步的testing来发现问题出在哪里,但是有一个bug与xamarin bugzillalogging,这似乎与我们所遇到的问题类似。 基本上我们尝试了以下,对我们来说已经足够了。

我们切换到使用unix套接字与下面的命令参数

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

我们使用这种方法的问题是,每次运行fastcgi-mono-server4时,套接字文件的权限都会发生变化,因此您必须在启动fastcgi-mono-server4后才能更正它们! 另一个缺点是在我们的机器上,它只能处理约120个并发请求。 然而,这对我们目前来说并不是一个真正的问题,你总是可以产生更多的stream程。

希望这可以帮助

免责声明:我是HyperFastCgi服务器的作者,博客文章的作者是在ceco的答案中提到的

nginx与HyperFastCgi做这个工作。 HyperFastCgi不会将内存泄露为单声道fastcgi服务器,并且执行速度更快,因为它使用低级单声道API在应用程序域之间传递数据,而不是跨域调用的慢单声道JIT实现。 它也可以select使用原生的libevent库进行套接字通信,比现在的单一System.Net.Sockets实现快大约1.5-2倍。

HyperFastCgi的主要function:

  • 允许使用3种不同的方式处理套接字和跨域通信:
    • Managed Listener with Managed Transport (仅使用托pipe代码,asynchronousSystem.Net.Sockets。由于缓慢的JIT跨域调用,单声道速度慢)
    • Managed Listener with Combined Transport (使用asynchronousSystem.Net.Sockets作为侦听Managed Listener with Combined Transport使用低级单声道API进行跨域调用,速度要快得多)
    • Native Listener (使用native libevent作为套接字库和低级别mono API进行跨域调用,性能最佳)
  • 允许多种方式来并行处理Web请求:使用ThreadPool,.NET 4.5任务或单线程。 最后一个选项与Native Listener结合使得Web服务器像NodeJS一样工作:所有请求都以asynchronous方式在单线程中处理。
  • 允许编写简单的请求处理程序,而不使用System.Web。 这提高了2-2.5次的处理性能。

有一个有用的和相对较新的博客文章关于使用ServiceStack Mono的性能。 我认为这可能是有用的决定如何承载他们的服务: 在单声道的性能

正如它所说 – FastCGI Mono服务器有大量的内存泄漏,我可以确认。 我使用Mono 3.2.8和Nginx 1.4.6以及FastCGI Mono Server 3.0.11和使用ServiceStack 3.9.71编写的服务在Ubuntu桌面14.04上运行ab -n 100000 -c 10 http://myurl 。 因为FastCGI单一服务器是漏洞,所以我认为它不关心我使用哪个版本的ServiceStack。 它吃了所有可用的内存 – 总共2GB中大概有1Gb。

另外,Nginx + FastCGI Mono Server的性能不好 ,至less与其他解决scheme相比。 我的示例REST服务每秒约有275个请求。 博客的作者已经回顾了FastCGI Mono Server的代码并决定编写他自己的实现。 由于某种原因,至less在我的机器上,它不工作。

所以我想,关键是你不应该使用FastCGI单声道服务器。 除非你想经常重启机器。

由于这个post大多是负面的,我应该说我的意图是什么主办我的服务。 我可能会用AppHostinheritanceAppHostHttpListenerLongRunningBase后面的AppHostHttpListenerLongRunningBase。 使用上面相同的示例REST服务,我每秒获得约1100个请求。 更好的消息是这个过程没有明显的泄漏,我testing了大约1 000 000个请求,并且这个过程消耗了<100MB的RAM。

PS我不是博客文章的作者:)

evhttp-sharp – 与NancyFx主机的http服务器

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

非常快,几乎比nancy-libevent2快4倍。

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

有不同configuration的testing结果:

每秒JSON响应:

  • evhttp-sharp 91,557
  • nancy-libevent2 17,338
  • servicestack-nginx -d 953
  • 南希896
  • aspnet-jsonnet -mon 863