系统相关
首页 > 系统相关> > c# – linux / mono上的HTTP性能

c# – linux / mono上的HTTP性能

作者:互联网

我的问题
由于有一些代码可以支持这个问题 – 我会先提出来.在linux / mono上运行的Servicestack自托管服务(或者实际上是任何http侦听器)是否存在任何已知的性能问题?

我的实际用例是用于调用多个其他(非公共)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).基本上 – 下面的代码中没有任何内容应该对下面的服务定义的硬件过度征税.我也试过在其他虚拟机上托管以确保它不是我的本地硬件 – 但无论我在哪里尝试,我似乎都能获得一致的结果.
我使用mono:latest image和xbuild my 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();
    }

}

结果:

因此,在我的本地窗口框中,每次请求可以在0.1秒到0.02秒之间润湿.经过多次尝试后,对于100个请求,平均值大约为0.1秒.

如果我将测试应用程序指向linux框 – 与在docker容器中使用mono编译并运行的相同代码 – 我看到大多数请求在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服务,并且该服务也表现出相同的行为.
救命!

解决方法:

v4.5.2更新

ServiceStack在其v4.5.2 Release中添加了对.NET Core的支持,现在是在Linux上运行ServiceStack的推荐和支持选项.

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

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

> https://github.com/ServiceStackApps/mono-server-config
> https://github.com/ServiceStackApps/mono-docker-config

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

标签:c,mono,servicestack,nancy,httplistener
来源: https://codeday.me/bug/20190608/1198819.html