需要有关HttpClient和JSON序列化的性能建议 [英] Need performance advice for HttpClient and JSON serialization

查看:196
本文介绍了需要有关HttpClient和JSON序列化的性能建议的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

大家好,我是网络编程的新手,刚刚完成了我的第一个RESTful客户端/服务器对".我的服务器是用ASP.NET核心编写的Web api,客户端是使用HttpClient的完整框架WPF应用程序.我正在尝试发送对象 包含一些简单的数据类型,包括字节数组.该阵列通常约为4MB左右,但可能更大.我已启动并运行它,但对性能不满意.虽然我在这些问题上经验不足,但我相信JSON序列化/反序列化 是罪魁祸首.这就是我所拥有的:

Hello all, I'm new to network programming and have just completed my first RESTful client/server "pair". My server is a web api written in ASP.NET core and the client is a full framework WPF application using HttpClient. I'm trying to send an object contaning some simple data types including an array of Bytes. The array is typically about 4MB or so but could be larger. I have it up and running but I'm unhappy with the performance. While I have little experience in these matters I believe the JSON serialization/deserialization is the culprit. Here's what I've got:

MY数据类:

    public class ByteData
    {
        public int Rows { get; set; }
        public int Columns { get; set; }
        public Byte[] Values { get; set; }
    }

在我的.NET Core服务器中,我按如下方式提供数据:

In my .NET Core server I serve up the data as follows:

        [HttpGet("/api/data")]
        public IActionResult GetImage()
        {
            if(MyServer.IsRunning)
            {
                return Ok(MyServer.byteData);
            }
            else
            {
                return NotFound("Not running");
            }
        }

其中"byteData"是"ByteData"类型的对象.在我的WPF客户端中,我按如下方式检索数据:

where "byteData" is an object of type "ByteData". In my WPF client I retrieve the data as follows:

HttpClient client = new HttpClient();           
client.BaseAddress = new Uri("http://localhost:8081/");
client.DefaultRequestHeaders.Accept.Clear();
client.DefaultRequestHeaders.Accept.Add(new MediaTypeWithQualityHeaderValue("application/json"));
ByteData dataImage = RetrieveData();

其中:

        private ByteData RetrieveData()
        {
            ByteData data = null;
            stopWatch.Reset();
            stopWatch.Start();

            HttpResponseMessage response = client.GetAsync("api/myData").Result;
            if (response.IsSuccessStatusCode)
            {
                data = response.Content.ReadAsAsync<ByteData>().Result;
            }

            stopWatch.Stop();
            timeLabel.Content = stopWatch.ElapsedMilliseconds.ToString();

            return data;
        }

典型的ByteData对象类似于:

And typical ByteData object is something like:

byteData = new ByteData();
byteData.Rows = 2028;
byteData.Columns = 2048;
byteData.Values = new Byte[byteData.Columns * byteData.Rows];

当我在客户端和服务器都运行在同一台计算机(即localhost)上以发布模式运行时,我的计时显示为约300ms,这在慢速端有点慢,因为我的阵列可能更大.在放置秒表的位置开始/停止 命令看起来像是在JSON序列化/反序列化中了.任何人对如何加快此速度的任何建议都将不胜感激!预先谢谢你.

When I run in release mode with both the client and server running on the same machine (i.e. localhost) my timings are showing about 300ms, which is a little on the slow side since my arrays may be larger. From where I've placed the stopwatch Start/Stop commands it looks like the time is in the JSON serialization/deserialization. Any advice anyone may have on how to speed this up is much appreciated! Thank you in advance.

-L

推荐答案

>>在其中放置了秒表Start/Stop命令的地方,时间似乎已经到了JSON序列化/反序列化

>>where I've placed the stopwatch Start/Stop commands it looks like the time is in the JSON serialization/deserialization

对于API客户端和服务之间的性能,我发现您在客户端使用了"response.Content.ReadAsAsync< ByteData>().Result".据我所知,json格式化程序是Asp.net Core服务器端最快的.没有速度设置 序列化.

For performance between API client and service, I found you have used "response.Content.ReadAsAsync<ByteData>().Result" at client side. As far as I know, the json formatter is the fastest in Asp.net Core server side. There are no settings to speed up the serialization.

此外,我认为300ms可以.我建议您尝试下载一个大文件,以检查性能是否不被接受.

In addition, I think 300ms is ok. I suggest you try to download a large file to check whether the performance is not accepted. 


这篇关于需要有关HttpClient和JSON序列化的性能建议的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆