Linux/Mono环境下的HTTP性能

4

我的问题
由于此问题涉及到一些代码,我将在前面提出。 Servicestack自托管服务(或任何http监听器)在Linux / mono上运行时是否存在已知的性能问题?

我的实际用例是用于调用多个其他(非公共)Web服务的Web服务。当在Windows下运行时,我注意到性能非常快,但当在Linux / mono下运行时,它似乎变慢,一个请求可能需要长达15秒的时间(与在Windows下运行时的0.2秒相比)。

我的后续问题是 - 我是否做错了什么?

.

我的环境
我正在运行一个Windows 10 PC - i7-6700 @ 3.4ghz 4核 - (超线程 - 因此有8个逻辑核心),32GB内存,并使用hyper V运行一个Linux VM(Ubuntu 16.04)。它拥有2个核心(i7-6500@3.4ghz - 分配给4GB Ram)。基本上 - 在下面的代码中没有任何东西应该超负荷支撑服务定义下面的硬件。我还尝试将其托管在其他VM上,以确保不是我的本地硬件 - 但无论我尝试什么,结果似乎都很一致。
我使用mono:latest映像并构建C#解决方案来创建一个docker映像,我将其托管在Linux机器上。
此外 - 我对Linux的世界非常陌生 - 还不知道如何在该平台上进行故障排除(但有些头疼!)

其中一个服务的示例

程序类:适用于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 秒之间的时间。多次尝试后,平均值约为 0.1 秒,100 个请求。

如果我将测试应用程序指向运行在 Docker 容器中的 Mono 下的相同代码 - 在 Linux 上执行 - 我发现大多数请求的响应时间在 0.8 秒到 0.05 秒之间,但几乎每次尝试时我都会看到一些请求需要等待 15 秒才能服务完毕。在 Mono/Linux 上比 .NET/Windows 慢得多!

顺便说一句,如果我将并行循环从 100 增加到 500,我发现 Windows 服务可以轻松处理所有请求,但是客户端应用程序(我的测试程序)会出现 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%。该服务并没有做什么费力的事情。

请注意 - 我正在尝试让多个服务彼此通信 - 此处显示的服务是一个非常简化的“测试用户”服务。我发现当服务调用其他服务(每个服务在自己的docker容器中运行)时,通信所需的时间过长,无法接受。
我之所以只向您展示一个服务,是因为可以演示多次调用服务会明显减速。

我不确定这是否是由服务堆栈引起的问题,因为我还有一个自托管的Nancyfx服务正在运行,该服务也表现出相同的行为。 救命啊!

1个回答

5

v4.5.2 更新

ServiceStack 在其v4.5.2 发布版中增加了对 .NET Core 的支持, 现在已成为在 Linux 上运行 ServiceStack 的推荐和受支持选项。


一个 Servicestack 自托管服务(或者任何 http 监听器)在linux/mono上运行时是否存在已知的性能问题?

Mono 的 HTTP 堆栈对于重负载是缓慢且不稳定的,对于小负载来说可以使用,但我们不建议将其用于生产负载。我们记录了我们发现的最可靠的在 Mono 上运行的设置,使用 HyperFastCI + Nginx ,例如:

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


1
我之前正在研究ServiceStack对.NET Core的支持,我有点希望你能回答类似这样的问题!我将非常期待发布公告。我会在明天早上查看你发布的链接。谢谢! - Jay
1
@Jay FYI,我们刚刚发布了ServiceStack的.NET Core支持 :) - mythz
哈哈,真巧!我刚刚查看了这篇帖子,但它还没有发布在这里:https://forums.servicestack.net/c/announcements - 谢谢你告诉我 :) - Jay

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接