dotnet/aspnetcore#30769删除了每个连接的 PipeOptions 分配 ， 并将该分配移动到连接工厂 ， 因此我们只分配一个服务器的整个生命周期 ， 并为每个连接重用相同的选项 。 来自@benaadams 的 dotnet/aspnetcore#31311 将 WebSocket 请求中众所周知的标头值替换为内部字符串 ， 这允许在头解析过程中分配的字符串被垃圾回收 ， 减少了长期存在的 WebSocket 连接的内存使用 。 dotnet/aspnetcore#30771 重构了 Kestrel 中的 Sockets 层 ， 首先避免分配 SocketReceiver 对象+ SocketAwaitableEventArgs ， 并将其合并为单个对象 ， 这节省了几个字节 ， 并导致每个连接分配的对象较少 。 该 PR 还汇集了 SocketSender 类 ， 因此您现在平均拥有多个核心 SocketSender ， 而不是为每个连接创建一个 。 因此 ， 在下面的基准测试中 ， 当我们有10,000个连接时 ， 在我的机器上只分配了16个连接 ， 而不是10,000个 ， 这节省了~ 46mb !
另一个类似的大小变化是 dotnet/runtime#49123 ， 它增加了对 SslStream 中零字节读取的支持 ， 这样我们的10,000个空闲连接从 SslStream分配的~ 46mb到~2.3 MB 。 dotnet/runtime#49117 在 StreamPipeReader 上添加了对零字节读取的支持 ， 然后 Kestrel 在 dotnet/aspnetcore#30863 中使用它开始在 SslStream 中使用零字节读取 。
所有这些变化的最终结果是大量减少空闲连接的内存使用 。
下面的数字不是来自于 BenchmarkDotNet 应用程序 ， 因为它测量空闲连接 ， 而且更容易用客户机和服务器应用程序进行设置 。
控制台和 WebApplication 代码粘贴对应的要点中：
下面是10000个空闲的安全 WebSocket 连接(WSS)在不同框架上占用服务器的内存 。

文章图片

这比 net5 减少了近 4 倍的内存 。

• dotnet/runtime#49270
  https://github.com/dotnet/runtime/pull/49270
  
• dotnet/aspnetcore#31308
  https://github.com/dotnet/aspnetcore/pull/31308
  
• dotnet/aspnetcore#30769
  https://github.com/dotnet/aspnetcore/pull/30769
  
• benaadams
  https://github.com/benaadams
  
• dotnet/aspnetcore#31311
  https://github.com/dotnet/aspnetcore/pull/31311
  
• 内部字符串
  https://en.wikipedia.org/wiki/String_interning
  
• dotnet/aspnetcore#30771
  https://github.com/dotnet/aspnetcore/pull/30771
  
• dotnet/runtime#49123
  https://github.com/dotnet/runtime/pull/49123
  
• dotnet/runtime#49117
  https://github.com/dotnet/runtime/pull/49117
  
• dotnet/aspnetcore#30863
  https://github.com/dotnet/aspnetcore/pull/30863
  
• 对应的要点
  https://gist.github.com/BrennanConroy/02e8459d63305b4acaa0a021686f54c7
  

实体框架核心
EF Core 在6.0版本中做了大量的改进 ， 查询执行速度提高了31% ， TechEmpower fortune 的基准运行时间更新、优化基准和EF的改进提高了70% 。
这些改进来自于对象池的改进 ， 智能检查是否启用了遥测技术 ， 以及添加一个选项 ， 当你知道你的应用程序安全地使用 DbContext 时 ， 可以选择退出线程安全检查 。
请参阅发布实体框架核心6.0预览版4:性能版的博客文章 ， 其中详细强调了许多改进 。
Blazor 本机 byte[] 互操作
Blazor 现在在执行 Java 互操作时对字节数组有了有效的支持 。 以前 ， 发送到和从 Java 的字节数组是 Base64 编码的 ， 因此它们可以被序列化为 JSON ， 这增加了传输大小和 CPU 负载 。 Base64 编码现在已经在 .NET6 中进行了优化 ， 允许用户透明地使用 .NET中 的 byte[] 和 Java 中的 Uint8Array 。 说明如何将此特性用于 Java 到 .NET 和 .NET 到 Java 。