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

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

• XSP
• 是mod_mono
• FASTCGI
• 安慰

什么是这些不同的configuration，哪些是Mononetworking服务的首选？

Answer 1

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的示例应用程序

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

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

Answer 2

在生产中，我们使用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程。

希望这可以帮助

Answer 3

免责声明：我是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次的处理性能。

Answer 4

有一个有用的和相对较新的博客文章关于使用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我不是博客文章的作者:)

Answer 5

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