【发布时间】：2021-01-18 10:15:16
【问题描述】：
我们正在开发一个基于 ASP.NET 和 ASP.NET Core 3.1 的系统。 最近，在基于负载测试进行改进时，我们发现了一个 API-Endpoint，它可以处理文件上传和一些 JSON 负载（它是一个多部分请求）。
虽然这个端点成为瓶颈并不奇怪，但我认为还有一些改进的余地。
热门路径
关键路径似乎是文件上传管理。 最多可以上传 25 个文件（我们的负载测试发送一个 2MB 文件，因为这是平均值）。
端点获取 IFormFiles，并将其 Stream-Contents 分配给 DTO 的 byte[] 属性，然后将其发送到基于 .NET（非核心）的另一个服务，因为它需要 SharePoint SDK不支持 .NET Core :(.
所述服务将byte[] 读取到流中，该流被发送到最终存储文档的 SharePoint。
我的问题
我猜（不知道） Request → IFormFile.Stream → byte[] → Stream → SharePoint 链可以在没有转换为和的情况下实现来自byte[]。
这可能吗？如果可能的话：它会提高整体操作的性能吗？
换句话说：是否可以通过另一个请求将IFormFile 的内容流式传输到中间WebService？ （这有意义吗）
【问题讨论】：
-
您是否进行了任何分析以检查瓶颈在哪里？我希望从/到流的转换最多是一个副本，并且仅复制字节相当快。
-
是的，但从我读过的内容来看，IFormFile 将整个文件缓冲在内存中，这可能解释了为什么速度如此之慢。如果我们执行我们的负载测试套件并跳过上传部分（仍然使用相同的端点），它会尽可能快。这就是为什么我认为这是问题所在。分析有点困难，因为问题出现在“重负载”exclusivley 下。当应用程序空闲时，负载测试场景在 1 秒内执行所述操作。在负载下，它的平均时间约为 30 秒。最多超过 60 秒（超时）。
-
另外，使用带有本地模拟的共享点执行加载场景很慢（写入磁盘而不是将其发送到我们的共享点服务，即使在负载下它也相当快。也许它自己的共享点是问题在这里。很难调查。
标签： c# asp.net asp.net-core stream