可以考虑接上 .NET 自带的 OpenTelemetry 集成？ https://learn.microsoft.com/dotnet/core/diagnostics/observability-with-otel
这样可以详细跟踪你的 asp.net core 的各接口甚至是数据库查询的执行情况，然后你只需要用 Jaeger 之类的就能做分布式追踪。

主要区别就是把原来 Java 写的引擎换成了 .NET 写的，并且跟进 ReSharper C++ 那边的特性，性能得到了不小的提升，资源占用也改善了很多，并且对现代 C++ 代码支持的也更完善。

把 Windows 功能里把 Linux 子系统关掉，然后再运行 wsl --install 。功能里的那个 wsl 是旧版的现在已经弃用了。

@89ao 你可以带上 -Verbose 看看，比如 nuget list -Verbose
我这里跑了一下，很明显在发送下一个请求的时候中间停了一小会儿，我怀疑是客户端为了限制频率故意添加的延时。

去下载个 dism++，里面有个系统备份可以直接把你整个系统盘备份成个镜像，允许你后续安装。文件应用什么的全都保留。

@89ao 可能是网络问题？试试本地搭一个看看呢？ nuget server 有不少开源实现，比如 https://github.com/bagetter/BaGetter

@drymonfidelia 试了一下没问题啊，折叠后仍然可以展开，你 F12 打开看看控制台，该不会是什么资源被墙了吧。

不需要保持 http 连接的，nuget server 的 API 都是 REST API ，因为包太多了所以不会一次性返回所有的包，于是你调用 nuget list 只是从 nuget api 上在那里分页式地一页一页加载数据罢了。
正常用 nuget list 要配合关键词搜索来使用，哪有不给关键词一次性列出全部包的。

简单在我自己的电脑上跑了一下 memtier_benchmark：
memtier_benchmark -t 4 -c 50 --pipeline=1024 -n 1000000

Redis：

ALL STATS
============================================================================================================================
Type Ops/sec Hits/sec Misses/sec Avg. Latency p50 Latency p99 Latency p99.9 Latency KB/sec
----------------------------------------------------------------------------------------------------------------------------
Sets 408346.45 --- --- 46.40698 42.23900 66.04700 70.14300 31458.55
Gets 4083419.55 18668.12 4064751.43 46.35596 42.23900 66.04700 70.14300 159685.06
Waits 0.00 --- --- --- --- --- --- ---
Totals 4491766.00 18668.12 4064751.43 46.36059 42.23900 66.04700 70.14300 191143.62

Garnet：

ALL STATS
============================================================================================================================
Type Ops/sec Hits/sec Misses/sec Avg. Latency p50 Latency p99 Latency p99.9 Latency KB/sec
----------------------------------------------------------------------------------------------------------------------------
Sets 1009126.20 --- --- 18.53643 17.79100 29.69500 35.58300 77741.95
Gets 10091151.04 91566.19 9999584.85 18.51609 17.79100 29.69500 35.58300 396130.24
Waits 0.00 --- --- --- --- --- --- ---
Totals 11100277.24 91566.19 9999584.85 18.51794 17.79100 29.69500 35.58300 473872.19

确实 Garnet 无论是吞吐量还是延时都碾压了 Redis 。

哪怕设置 --pipeline=1 让 benchmark 跑完一个请求之后再发下一个请求的这种利好 redis 的单线程测试场景，garnet 一样跑出了比 redis 更好的成绩。

直接锁卡就行了，等对面扣不了钱的时候自己就会跟你发邮件联系的。

@KAMx 他们做的时候就是挑着自己需要用的命令优先做的，满足了需求就上生产了。
其实就算是用 redis 也不见得所有命令都会用得到。

@sloknyyz 这玩意是微软研究院 2021 年开始做，最近终于搞出来的玩意。
另外 Azure 已经内部把 Redis 换成这个 Garnet 上生产上了几个月了。

> 如果用 Genymotion 安卓虚拟机就能明显感受到

有没有可能是因为 Genymotion 不兼容 Hyper-V 的硬件虚拟化才导致的性能问题，这要说也是 Genymotion 自己的问题吧。

建议跑 Windows server 2022 。
另外如果不急的话其实可以等年底的 Windows server 2025 ，2025 引入了 hotpatching 可以在不重启的情况下热更新。

其实可以参考这篇文章给你的 RDP 添加多因素认证，这样就算破解进来了一样要输入动态口令才能访问： https://inc.sysu.edu.cn/article/1050

Edge 正式版 122 好像确实有 bug ，会导致各种卡死。
感觉该不会是微软把什么开发中的还不稳定的特性 flag 没关掉，发布到正式版去了吧。
作为解决方案，可以考虑去安装个 Edge 的 insider 版本，比如 beta 或者 dev ，反正数据都是同步的。

@hez2010 #30 楼上本来是打算回复 @flyqie #27 的，结果忘记 mention 了。

RDP 其实是开放协议，也有不少很完整的开源实现的，最著名的比如 https://github.com/FreeRDP/FreeRDP ，这个 FreeRDP 也被微软用在了 WSLg 里面，可以说是官方认可了。
不过 RDP 涉及到的协议实在是太多了，从差分算法，到图像到音频到视频编码，再到网络协议和 GPU 硬件加速等等，一般人很能全都实现完： https://github.com/FreeRDP/FreeRDP/wiki/Reference-Documentation

@playboy0 组策略里：计算机配置——管理模板——Windows 组件——远程桌面服务——远程桌面会话主机——远程会话环境，开启优先 H.264/AVC 444 和 H.264/AVC 444 硬件编码这两个选项