linux/mono 上的 HTTP 性能

Question

我的问题
由于有一些代码可以支持这个问题 - 我会提前询问。 linux/mono 上的 Servicestack 自托管服务（或任何 http 侦听器）运行是否存在任何已知的性能问题？

我的实际用例是用于调用多个其他（非public）Web 服务的 Web 服务。当 windows 下的运行时，我注意到性能快得令人眼花缭乱，但是当 linux/mono 下的运行时 - 它似乎变慢了，请求的长度可能长达15 秒（相比 windows 下的 0.2 秒运行）。

我的后续问题是 - 我在这里做错了什么（如果有的话）？

.

我的环境
我是运行一台 Windows 10 台 PC - i7-6700 @ 3.4ghz 4 核 -（超线程 - 所以 8 个逻辑核），32GB 内存，并且有一个 Linux 虚拟机（Ubuntu 16.04) 使用 hyper V。它有 2 个内核（i7-6500@3.4ghz - 分配给它的 4GB Ram）。基本上 - 下面的代码中的任何内容都不应该对下面的服务定义下的硬件过度征税。我也试过将它托管在其他虚拟机上，以确保它不是我的本地硬件 - 但无论我在哪里尝试，我似乎都能得到一致的结果。
我使用 mono:latest 图像和 xbuild 我的 C# 解决方案来创建我在 linux 机器上托管的 docker 图像。
另外 - 我对 Linux 的世界还很陌生 - 不太确定如何在这个平台上进行故障排除（还！）

其中一项服务的示例

程序class：适用于windows/linux:

 class Program
{
    static void Main(string[] args)
    {
        var listeningOn = args.Length == 0 ? "http://*:32700/api/user/" : args[0];
        var appHost = new AppHost()
            .Init()
            .Start(listeningOn);

        Console.WriteLine("AppHost Created at {0}, listening on {1}",
            DateTime.Now, listeningOn);

        // check if we're running on mono
        if (Type.GetType("Mono.Runtime") != null)
        {
            // on mono, processes will usually run as daemons - this allows you to listen
            // for termination signals (ctrl+c, shutdown, etc) and finalize correctly
            UnixSignal.WaitAny(new[]
            {
                new UnixSignal(Signum.SIGINT),
                new UnixSignal(Signum.SIGTERM),
                new UnixSignal(Signum.SIGQUIT),
                new UnixSignal(Signum.SIGHUP)
            });
        }
        else
        {
            Console.ReadLine();
        }
    }
}

应用主机：

public class AppHost : AppSelfHostBase
{
    public AppHost() : base("Test User Service", typeof(AppHost).Assembly)
    {
        Plugins.Add(new PostmanFeature());
        Plugins.Add(new CorsFeature());
    }

    public override void Configure(Container container)
    {
    }   
}

合同：

[Api("Get User"), Route("/getUserByUserIdentifier/{Tenant}/{Identifier}", "GET")]
public class GetUserByUserIdentifierRequest : IReturn<GetUserByUserIdentifierResponse>
{
    public string Tenant { get; set; }
    public string Identifier { get; set; }
}

public class GetUserByUserIdentifierResponse
{
    public UserDto User { get; set; }
}

public class UserDto
{
    public string UserName { get; set; }
    public string UserIdentifier { get; set; }
}

我用来测试应用程序的独立控制台：

class Program
{
    static void Main(string[] args)
    {
        Console.WriteLine("Starting...");

        ConcurrentBag<long> timings = new ConcurrentBag<long>();

        Parallel.For(0, 100, new ParallelOptions { MaxDegreeOfParallelism = 8 }, x =>
        {
            Console.WriteLine("Attempt #{0}", x);
            using (JsonServiceClient client = new JsonServiceClient("http://127.0.0.1:32700/api/user/")) //Specify Linux box IP here!
            {
                Stopwatch sw = new Stopwatch();
                Console.WriteLine("Stopwatch started...");
                sw.Start();
                GetUserByUserIdentifierResponse response = client.Get(new GetUserByUserIdentifierRequest {Tenant = "F119A0DF-5002-4FF1-A0CE-8B60CFEE16A2", Identifier = "3216C49E-80C9-4249-9407-3E636E8C58AC"});
                sw.Stop();
                Console.WriteLine("Stopwatch stopped... got value [{0}] back in {1}ms", response.ToJson(), sw.ElapsedMilliseconds);
                timings.Add(sw.ElapsedMilliseconds);
            }
        });

        var allTimes = timings.ToList();

        Console.WriteLine("Longest time taken = {0}ms", allTimes.Max());
        Console.WriteLine("Shortest time taken = {0}ms", allTimes.Min());
        Console.WriteLine("Avg time taken = {0}ms", allTimes.Average());

        Console.WriteLine("Done!");
        Console.ReadLine();
    }

}

结果：

所以在我的本地 windows 盒子上，每个请求可能需要 0.1 秒到 0.02 秒。多次尝试后，100 个请求的平均耗时约为 0.1 秒。

如果我将测试应用程序指向 linux 框 - 指向在 docker 容器中的单声道下使用和运行编译的相同代码 - 我看到大部分请求的响应时间在 0.8 秒到 0.05 秒之间，但我确实看到（几乎每次尝试时）有些请求需要 15 秒才能得到响应。这在 Mono/linux 上比在 .NET/Windows 上慢很多！

顺便说一句，如果我将并行循环从 100 增加到 500，我发现 windows 服务可以毫不费力地处理所有请求，但是 client 应用程序（我的测试程序）将因 IO 错误而失败：

System.IO.IOException was unhandled by user code
HResult=-2146232800
Message=Unable to read data from the transport connection: The connection was closed.
Source=System
StackTrace:
   at System.Net.ConnectStream.Read(Byte[] buffer, Int32 offset, Int32 size)
   at System.IO.StreamReader.ReadBuffer()
   at System.IO.StreamReader.ReadToEnd()
   at ServiceStack.Text.JsonSerializer.DeserializeFromStream[T](Stream stream)
   at ServiceStack.Serialization.JsonDataContractSerializer.DeserializeFromStream[T](Stream stream)
   at ServiceStack.JsonServiceClient.DeserializeFromStream[T](Stream stream)
   at ServiceStack.ServiceClientBase.GetResponse[TResponse](WebResponse webResponse)
   at ServiceStack.ServiceClientBase.Send[TResponse](String httpMethod, String relativeOrAbsoluteUrl, Object request)
   at ServiceStack.ServiceClientBase.Get[TResponse](IReturn`1 requestDto)
   at httppoke.Program.<>c__DisplayClass0_0.<Main>b__0(Int32 x) in <Redacted>\Program.cs:line 30
   at System.Threading.Tasks.Parallel.<>c__DisplayClass17_0`1.<ForWorker>b__1()
InnerException:

我觉得这个错误可能有助于指示发生了什么，但我真的不知道如何在我面临的问题的上下文中解释它。

还值得注意的是，在 linux 机器上观看 'top' 或 'docker stats' 而测试程序是运行， CPU使用率永远不会超过 4%。该服务并没有做任何繁重的工作。

请注意 - 我正在尝试让多个服务相互通信 - 此处显示的服务是 'test user' 服务的精简版本。我发现当服务调用其他服务时（每个服务都在它自己的 docker 容器中运行）- 服务之间通信所花费的时间长得令人无法接受。
我在这里只向您展示所有一项服务的原因是，可以证明对一项服务的多次调用似乎明显变慢。

我不确定这是不是由服务堆栈引起的问题，因为我也有一个自托管的 Nancyfx 服务运行，而且该服务也有同样的行为。帮助！

Answer 1

v4.5.2 更新

ServiceStack 在其 v4.5.2 Release 中添加了对 .NET Core 的支持，现在它是运行ning ServiceStack 在 Linux.

上的推荐和支持选项

Are there any known performance issues with a Servicestack self host service (or indeed any http listener) running on linux/mono?

Mono 的 HTTP 堆栈对于繁重的工作负载来说速度慢且不稳定，它适用于小型工作负载，但我们不建议将其用于生产工作负载。我们已经记录了我们发现的最可靠的设置运行在 Mono 上使用 HyperFastCI + nginx，例如：

在 Linux 上托管 ServiceStack 和 .NET 的未来是 .NET Core，它快速、稳定且得到良好支持。 ServiceStack 对 .NET Core 的支持将在本周晚些时候发布的下一个 v4.5.2 发行说明中公布。

linux/mono 上的 HTTP 性能

HTTP performance on linux/mono

c#

mono

httplistener

servicestack

nancy

v4.5.2 更新