asp.net core mvc 是不是未包含使用UA 动态选择displayModel 10
尝试使用core是因为微软宣称性能提升10倍,还有新的taghelper,还有生成跨平台应用方便。。但是并发测试性能并未发现提升(放iis里),以前framework支持...
尝试使用core 是因为微软宣称 性能提升10倍,还有新的taghelper,还有生成跨平台应用方便。。但是并发测试性能并未发现提升(放iis里),以前framework支持的东西,现在core 里都不知道到什么地方去写。。不考虑生成良好的跨平台应用,真不觉得比framework有什么优势
展开
2个回答
展开全部
这个吧,可能有些东西你不太理解造成的。
关于性能提升的问题,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!
关于性能提升的问题,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 进行的呢?
网易云信
2023-12-06 广告
2023-12-06 广告
UIkit是一套轻量级、模块化且易于使用的开源UI组件库,由YOOtheme团队开发。它提供了丰富的界面元素,包括按钮、表单、表格、对话框、滑块、下拉菜单、选项卡等等,适用于各种类型的网站和应用程序。UIkit还支持响应式设计,可以根据不同...
点击进入详情页
本回答由网易云信提供
推荐律师服务:
若未解决您的问题,请您详细描述您的问题,通过百度律临进行免费专业咨询