asp.net core mvc 是否未包含使用UA 动态选择displayModel

Posted 2023-03-09

尝试使用core 是因为微软宣称 性能提升10倍，还有新的taghelper，还有生成跨平台应用方便。。但是并发测试性能并未发现提升(放iis里)，以前framework支持的东西,现在core 里都不知道到什么地方去写。。不考虑生成良好的跨平台应用，真不觉得比framework有什么优势

这个吧，可能有些东西你不太理解造成的。
关于性能提升的问题，net core是否性能提升10倍？答案是还真差不多！为什么呢？这是因为.net core为了跨平台，编译的方式使用的是dotnet publish -r 版本，例如发布到windows X64的机器上，使用的命令就应该是dotnet publish -r win-x64这样的命令进行发布。而运行方式呢，使用的是dotnet run xx.dll，或者直接dotnet xx.dll，它并不依赖于IIS！当然可以在IIS上部署，也就是在配置文件中使用dotnet 其中参数为xx.dll效果是一样的——但是一旦这样部署的样，受制于IIS（多数情况下使用的是IIS10.0），尤其多线程测试时weblimit参数不做更新的话，性能上有影响，即使数据很大也是有影响的。
当然如果你直接使用IIS把源码丢过去，在配置文件中使用允许编译的方式的话，这种方式其实与.net framework的效果是一样的，并没有任何性能上的优势——这种情况只是你把net core看作是net framework的一个版本一样，他自然和其他版本相关不大！所以你不说话你的测试方式自然性能上无法估量。
net core相比之下的优势其实除了性能上的提高就是跨平台（其实是源码跨平台），什么意思呢？.net framework的移植性非常好，生成一个通用的dll（MSIL中间文件），然后该文件由不同机器上的运行环境自行翻译（JIT功能），一般认为是边翻译边执行，当然为了整体的性能问题，JIT首次编译的内容（调用的片段才会被翻译，不调用的不会翻译）存储到Native上，下次再调用时不用翻译过的代码时，JIT会跳过翻译，直接使用使用首次翻译过的片段。所以在以前的时候，有时我们为了性能，玩Native文件，而netcore后边指定版本的作用，其实就是翻译成可执行的二进制PE文件，当然他需要指定操作系统的，比如ubuntu等linux发行版上都可以的！想来看看，netcore本身在net framework上进行了重写，生成的也是针对不同系统的可执行内容，所以性能上肯定有所提升是绝对的。当然，这种方式最适合的方式还是容器方式（docker)，所以性能上要比在IIS上提升不少——当然不能是类似.net framework直接源码的形式，有点类似于.net framework,但是比framework发布的形式还要高些，而性能提升也是基本这两种形式的对比！

当然，严格来说.net core也是试水跨平台的方式，他去掉了.net framework的大多数内容，所以主要的体现就以下三点：
1,跨平台
2，重写库，性能上的提高
3，为docker做足准备（也是跨平台的扩展之一）
换句话来说，如果你不是基于以上几种的考虑，那么为什么要选择net core呢？要知道每种技术都有他适应的场景的，如果你是winform/WPF时，没有考虑net core的必要性，而且net core也不支持！如果是Azercloud的话，net core小巧，且服务专一，当然可以考虑net core.如果你公司考虑到使用linux发行版以避免高昂的windows费用，还有一堆.net程序员的话，net core肯定是你的选择优势——net framework不支持linux系统啊！
所以我认为技术只是适用！也不是用来比较，net framework与net core的定位是相当明显且不相互冲突，所以只是一种选择罢了，而不是谁一定比谁牛B！追问

请问你做的性能测试是基于什么容器 或 直接 donet run 进行的呢？

参考技术A w寄全椒山中道士(韦应物)