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

声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow 原文地址: http://stackoverflow.com/questions/12188356/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me): StackOverFlow

提示:将鼠标放在中文语句上可以显示对应的英文。显示中英文
时间:2020-08-06 14:13:00  来源:igfitidea点击:

What is the best way to run ServiceStack on Linux / Mono?

c#linuxmonoservicestackmod-fastcgi

提问by mythz

Listed on the ServiceStack websiteit shows that ServiceStack can run on Mono with either:

ServiceStack 网站上列出,它表明 ServiceStack 可以在 Mono 上运行:

  • XSP
  • mod_mono
  • FastCgi
  • Console
  • XSP
  • mod_mono
  • 快速Cgi
  • 安慰

What are these different configurations and which is preferred for Web Services on Mono?

这些不同的配置是什么,哪些是 Mono 上的 Web 服务的首选?

采纳答案by mythz

Update for Linux

Linux 更新

From the v4.5.2 ReleaseServiceStack now supports .NET Core which offers significant performance and stability improvements over Mono that's derived from a shared cross-platform code-base and supported by Microsoft's well-resourced, active and responsive team. If you're currently running ServiceStack on Mono, we strongly recommend upgrading to .NET Core to take advantage of its superior performance, stability and its top-to-bottom supported Technology Stack.

v4.5.2 版本开始,ServiceStack 现在支持 .NET Core,与 Mono 相比,它提供了显着的性能和稳定性改进,Mono 源自共享的跨平台代码库,并由 Microsoft 资源丰富、活跃且响应迅速的团队提供支持。如果您目前在 Mono 上运行 ServiceStack,我们强烈建议升级到 .NET Core 以利用其卓越的性能、稳定性和自上而下支持的技术堆栈。

Update for Mono

单声道更新

Our recommended Setup for hosting ASP .NET sites on Linux and Mono is to use nginx/HyperFastCgi. We've published a step-by-step guide going through creating an Ubuntu VM from scratch complete with deploy / install / conf / init scripts at mono-server-config.

我们推荐的在 Linux 和 Mono 上托管 ASP .NET 站点的设置是使用 nginx/HyperFastCgi。我们在mono-server-config发布了一个分步指南,介绍如何从头开始创建一个 Ubuntu VM,并带有 deploy/install/conf/init 脚本。

We're no longer recommending MonoFastCGI after noticing several stability and performance issues. This blog post provides a good analysis of the performance, memory usage and stability of the different ASP.NET Hosting options in Mono.

在注意到几个稳定性和性能问题后,我们不再推荐 MonoFastCGI。这篇博文很好地分析了Mono 中不同 ASP.NET 托管选项的性能、内存使用情况和稳定性。



Development

发展

XSPis similar to VS.NET WebDev server - a simple standalone ASP.NET WebServer written in C#. This is suitable for development or small work loads. You just run it from the root directory of your ServiceStack ASP.NET host which will make it available at http://localhost:8080.

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

Production

生产

For external internet services you generally want to host ServiceStack web services as part of a full-featured Web Server. The 2 most popular full-featured web servers for Linux are:

对于外部 Internet 服务,您通常希望将 ServiceStack Web 服务作为全功能 Web 服务器的一部分进行托管。用于 Linux 的 2 个最流行的全功能 Web 服务器是:

Nginx

nginx

Use Mono FastCGIto host ServiceStack ASP.NET hosts in Nginx.

使用Mono FastCGINginx 中托管 ServiceStack ASP.NET 主机。

Apache

阿帕奇

Use mod_monoto host ServiceStack ASP.NET hosts in an Apache HTTP Server.

使用mod_monoApache HTTP Server 中托管 ServiceStack ASP.NET 主机。

Self Hosting

自托管

ServiceStack also supports self-hosting which lets you run your ServiceStack webservices on its own in a standalone Console application (i.e. without a web server). This is a good idea when you don't need the services of a full-featured web server (e.g: you just need to host web services internally on an Intranet).

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

By default the same ServiceStack Console app binary runs on both Windows/.NET and Mono/Linux as-is. Although if you wish, you can easily daemonize your application to run as a Linux daemon as outlined here. The wiki page also includes instructions for configuring your self-hosted web service to run behind an Nginx or Apache reverse proxy.

默认情况下,相同的 ServiceStack 控制台应用程序二进制文件按原样在 Windows/.NET 和 Mono/Linux 上运行。尽管如果您愿意,您可以轻松地将您的应用程序守护进程以作为 Linux 守护程序运行,如此处所述。wiki 页面还包含有关配置自托管 Web 服务以在 Nginx 或 Apache 反向代理后运行的说明。

Since it provides a good fit for Heroku's Concurrency model as detailed in their 12 factor appself-hosting will be an area we'll be looking to provide increased support around in the near future.

由于它非常适合 Heroku 的并发模型,如其 12 因素应用程序自托管中所述,我们将在不久的将来寻求提供更多支持。

ServiceStack.net Nginx / Mono FastCGI configuration

ServiceStack.net Nginx / Mono FastCGI 配置

The servicestack.net website itself (inc. all live demos) runs on an Ubuntu hetzner vServerusing Nginx + Mono FastCGI.

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

This command is used to start the FastCGI background process:

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

Which hosts all applications defined in *.webapp files in the /etc/rc.d/init.d/mono-fastcgifolder specified using XSP's WebApp File Format, e.g:

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

ServiceStack.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>

This runs the FastCGI Mono process in the background which you can get Nginx to connect to by adding this rule to nginx.conf:

这将在后台运行 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;  
}

Which will forward any route starting with /ServiceStackor /RedisAdminUI, etc to the FastCGI mono server process for processing. Some example apps hosted this way:

它将任何以/ServiceStack或开头的路由转发/RedisAdminUI到 FastCGI 单声道服务器进程进行处理。以这种方式托管的一些示例应用程序:

For those interested the full Nginx + FastCGI configuration files for servicestack.net are available for download.

对于那些有兴趣的人,可以下载servicestack.net 的完整 Nginx + FastCGI 配置文件。

回答by Antony Denyer

In production we use nginx with unix file sockets

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

We found a bug/memory leak when using socket communication with nginx, service stack and mono. This was with 500 concurrent requests, whilst you'd expect a spike in cpu and memory it never came back down again. We didn't do any further testing to discover where the problem was but there is a bug logged with xamarin bugzillathat seems similar to the issues we had. Essentially we tried the following and it was good enough for us.

我们在使用与 nginx、服务堆栈和单声道的套接字通信时发现了一个错误/内存泄漏。这是有 500 个并发请求,而您预计 cpu 和内存会出现峰值,但它再也不会回落了。我们没有进行任何进一步的测试来发现问题出在哪里,但是xamarin bugzilla记录了一个错误,该错误似乎与我们遇到的问题相似。基本上我们尝试了以下方法,对我们来说已经足够了。

We switched to using unix sockets with the following command params

我们切换到使用带有以下命令参数的 unix 套接字

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

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

The problem we had with this method is that the permissions of the socket file changed everytime you run fastcgi-mono-server4 so you have to correct them after you've started fastcgi-mono-server4! The other downside is that on our boxes it could only handle about 120 concurrent requests. However this isn't really an issue for us at the moment and you can always spawn more processes.

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

Hope this helps

希望这可以帮助

回答by ceco

There is a helpful and relatively recent blog post regarding the performance of Mono using ServiceStack. I thought it could be of use to some who are about to decide how to host their services: Servicestack performance in Mono.

有一篇关于使用 ServiceStack 的 Mono 性能的有用且相对较新的博客文章。我认为它可能对一些即将决定如何托管他们的服务的人有用:Mono 中的 Servicestack 性能

As it says - the FastCGI Mono server has tonsof memory leaks which I can confirm. I ran ab -n 100000 -c 10 http://myurlon Ubuntu Desktop 14.04 using Mono 3.2.8 and Nginx 1.4.6 and FastCGI Mono Server 3.0.11 and a service written using ServiceStack 3.9.71. I don't think it matters which version of ServiceStack I am using since the FastCGI Mono Server is the leaky bit. It ate all the memory available - about 1Gb out of 2GB in total.

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

Also, the performance of Nginx + FastCGI Mono Server is bad, at least when compared to other solutions. My sample REST service had about 275 requests per second. The author of the blog had reviewed the code of FastCGI Mono Server and decided to write his own implementation. For some reason it's not working though, at least on my machine.

此外,Nginx + FastCGI Mono Server 的性能很差,至少与其他解决方案相比是这样。我的示例 REST 服务每秒大约有 275 个请求。博主查看了 FastCGI Mono Server 的代码,决定自己写实现。出于某种原因,它不起作用,至少在我的机器上。

So the point, I guess, is that you should notuse the FastCGI Mono Server. Unless you want to reboot your box often.

所以,我想,重点是你不应该使用 FastCGI Mono Server。除非你想经常重启你的盒子。

As this post is mostly negative I should say what are my intentions regarding hosting my services. I will probably go for self-hosting with an AppHost inheriting AppHostHttpListenerLongRunningBasebehind Nginx. Using the same sample REST service above I get about 1100 requests per second. The better news is that the process had no apparent leaks, I tested it with about 1 000 000 requests and the process had consumed < 100MB RAM.

由于这篇文章大多是负面的,我应该说我对托管服务的意图是什么。我可能会使用继承AppHostHttpListenerLongRunningBase在 Nginx 后面的 AppHost 进行自托管。使用上面相同的示例 REST 服务,我每秒收到大约 1100 个请求。更好的消息是该进程没有明显的泄漏,我用大约 1 000 000 个请求对其进行了测试,并且该进程消耗了 < 100MB RAM。

P.S. I am not the author of the blog post :)

PS我不是博文的作者:)

回答by Sergey Zhukov

Disclaimer: I'm the author of HyperFastCgi server and the author of blog post was mentioned in ceco's answer

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

nginx with HyperFastCgido this job. HyperFastCgi does not leak memory as mono fastcgi server and performs much faster, because it uses low-level mono API to pass data between application domains instead of slow mono JIT implementation of cross-domain calls. Also it has option to use native libeventlibrary for sockets communications which is roughly 1.5-2 faster than current mono System.Net.Sockets implementation.

带有HyperFastCgi 的nginx 可以完成这项工作。HyperFastCgi 不会像单声道 fastcgi 服务器那样泄漏内存并且执行速度更快,因为它使用低级单声道 API 在应用程序域之间传递数据,而不是慢速单声道 JIT 实现跨域调用。此外,它还可以选择使用原生libevent库进行套接字通信,这比当前的 Mono System.Net.Sockets 实现快 1.5-2 倍。

Key features of HyperFastCgi:

HyperFastCgi 的主要特点:

  • Allows to use 3 different ways to deal with sockets and cross-domain communication:
    • Managed Listener with Managed Transport(uses only managed code, asynchronous System.Net.Sockets. Slow in mono, due to slow JIT cross-domain calls)
    • Managed Listener with Combined Transport(uses async System.Net.Sockets as listener and low-level mono API for cross-domain calls. Much much faster)
    • Native Listener(uses native libeventas socket library and low-level mono API to make cross-domain calls. The best performance)
  • Allows several ways to parallel web requests: using ThreadPool, .NET 4.5 Task or Single-threading. Last options is combined with Native Listenermakes the web-server works like NodeJS: all requests are processed in single thread in asynchronous way.
  • Allows to write simple request handlers without using System.Web at all. This increases processing performance of requests for 2-2.5 times.
  • 允许使用 3 种不同的方式来处理套接字和跨域通信:
    • Managed Listener with Managed Transport(仅使用托管代码,异步 System.Net.Sockets。由于 JIT 跨域调用速度较慢,mono 中速度较慢)
    • Managed Listener with Combined Transport(使用异步 System.Net.Sockets 作为侦听器和用于跨域调用的低级单声道 API。快得多)
    • Native Listener(使用原生libevent作为socket库和低级mono API进行跨域调用,性能最佳)
  • 允许以多种方式并行 Web 请求:使用 ThreadPool、.NET 4.5 任务或单线程。最后一个选项与Native Listener使网络服务器的工作方式相结合NodeJS:所有请求都以异步方式在单线程中处理。
  • 允许在不使用 System.Web 的情况下编写简单的请求处理程序。这将请求的处理性能提高了 2-2.5 倍。

回答by mikowiec

evhttp-sharp - http server with host for NancyFx

evhttp-sharp - 带有 NancyFx 主机的 http 服务器

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

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

Very fast, almost 4 time faster than nancy-libevent2.

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

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

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

There are test results for different configurations:

有不同配置的测试结果:

JSON responses per second:

每秒 JSON 响应数:

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