.net - 为什么.NET OData 序列化器这么慢
问题描述
我有一个 OData 端点(使用 .NET Core 和 .NET 4.7.1 进行了测试),它公开了 2,500 个内置在内存中的对象。Get OData 调用需要 30-40 秒。返回原始 JSON 的等效 ASP.NET WEB API 调用需要 1 秒。感觉好像 OData 框架不如 Json.NET 高效。关于如何提高性能的任何建议?
真的很慢。
[EnableQuery(EnsureStableOrdering = false)]
public ActionResult<IEnumerable<Person>> Get()
{
var list = new List<Person>();
for (var i = 0; i < 2500; i++)
{
list.Add(new Person());
}
return list;
}
真的很快。
public IHttpActionResult Get()
{
var list = new List<Person>();
for (var i = 0; i < 2500; i++)
{
list.Add(new Person());
}
var json = JsonConvert.SerializeObject(list);
return Ok(json);
}
解决方案
好吧,答案不是序列化程序。添加 EnableQuery 时,默认情况下允许 OData 使用 Select、Count、Skip、Top、Expand 的不同方法。但最重要的是 EnableQuery 是一个 ActionFilterAttribute 这意味着:
ASP.NET Core 中的过滤器允许在请求处理管道中的特定阶段之前或之后运行代码。
在这里查看有关ActionFilters的更多信息
话虽如此,EnableQuery 覆盖了两种方法(之前/之后):
public override void OnActionExecuting(ActionExecutingContext actionExecutingContext)
和
public override void OnActionExecuted(ActionExecutedContext actionExecutedContext)
第一个是创建和验证查询选项的地方。这涉及到大量的反思工作。第二个检查结果是否已设置并成功,例如,如果您返回一个 IQueryable,这里是它被执行的地方。查询在此级别实现。它首先尝试从返回的响应消息中检索 IQueryable。然后,它根据“EnableQueryAttribute”上的验证设置验证来自 uri 的查询。它最终适当地应用查询,并将其重置回响应消息。
如您所见,所有这些额外的逻辑都比仅将结果转换为 JSON 输出(这是最后一步)更复杂。
我举了你的例子:
[ApiController]
[Route("api/test")]
public class WeatherForecastController : ControllerBase
{
[Route("/get1")]
[HttpGet]
[EnableQuery(EnsureStableOrdering = false)]
public ActionResult<IEnumerable<Person>> Get1()
{
var list = new List<Person>();
for (var i = 0; i < 2500; i++)
{
list.Add(new Person());
}
return list;
}
[Route("/get2")]
[HttpGet]
public IActionResult Get2()
{
var list = new List<Person>();
for (var i = 0; i < 2500; i++)
{
list.Add(new Person());
}
var json = JsonConvert.SerializeObject(list);
return Ok(json);
}
[Route("/get3")]
[HttpGet]
public IActionResult Get3()
{
var list = new List<Person>();
for (var i = 0; i < 2500; i++)
{
list.Add(new Person());
}
return Ok(list);
}
我用 20 个不同的线程对每个端点执行相同的请求进行性能测试:get1、get2、get3结果如下:
每个的平均毫秒数是:433,355,337 ,我认为这还不错,第一个是 Odata,与最后一个相比,这个负载测试只有 96 毫秒的差异。不知道为什么您的示例在这里需要 30-40 秒,因为我使用了相同的代码和 Jmeter 来进行负载测试,并且我得到的最大时间是 900 毫秒的一个请求,只有第一个请求,这很有意义,因为 apppool 是从第一个请求开始,以防它处于睡眠状态
恕我直言,如果您想实现所有可以使用 odata 执行的操作(整形、排序、分页、过滤器),您还需要大量使用反射,至少对于整形和过滤器,不要说所有也可用的二元运算符。创建你自己的语法,对我来说不是一个选项,你需要创建一个词法分析器和一个解析器来适应你自己的语法。所以我认为你得到的好处是巨大的,除非你的 API 不需要这些复杂的操作符。要考虑的一件事是如何扩展您的 api 以不损害性能,但这取决于您用于托管它的基础设施。希望这可以帮助。
推荐阅读
- c# - How to create a Winform in Unity and display it?
- python - 大熊猫过去 n 个日期的真实值总和
- java - Quick Question in regards to the Methods in Abstract Classes
- ios - Firebase pod 更新未更新
- github - How to sove the error 'The remote end hung up unexpectedly fatal: sha1 file '
' write error: Broken pipe error'? - javascript - 在javascript中执行函数无穷大
- java - How to use counter.countPrimes(1000000)?
- python - How to resolve the migration problem python?
- python-3.x - ValueError: Unrecognized backend string 'gtkagg': valid strings are ['GTK3Agg',
- flutter - Flutter 未定义名称 WhitelistingTextInputFormatter