如果发现你的dotnet core服务并发上不去，但cpu资源还比较充足那就要注意了!因为这很有可能是你没有设置一个运行项导致...,下面要提到的就是GC.Server这玩意，实际上项目编译中并没有这一项设置，通过app.config设置也无效。那到底这是一个什么东西接下来说一下实际的应用效果和配置方式。
原因
最近一直做在做FastHttpApi方面的性能测试，在本机测试性能一直都比较良好；问题部署上服务器后效率竟然跑不过asp.net core webapi,这结果和在本地测完全是两码事；主要原因是12核的CPU无法跑到超过8核的资源，而asp.net core基本能跑满！为了找到原因还把'Kestrel.Transport.Sockets'代码看了一遍，怎看也不看不出有本质上的性能优势，不过实测结果告诉我的确是这样了；于是又仔细翻阅了代码和配置文件也没看到有什么特别的配置和线程配置信息，后来实在没办法了又看了一遍发布后的配置信息，结果看了一个System.GC.Server的配置信息。
关于Server GC的解释
网上对System.GC.Server有实质性介绍的文档并不太多，MSDN翻译如下： 公共语言运行时 (CLR) 支持两种类型的垃圾回收：工作站垃圾回收（适用于所有系统）和服务器垃圾回收（适用于多处理器系统）。 使用 <gcServer> 元素以控制 CLR 执行的垃圾回收类型。 使用 GCSettings.IsServerGC 属性以确定是否启用服务器垃圾回收。 对于单处理器计算机，默认的工作站垃圾回收应该是最快捷的选项。 对于双处理器计算机，最快捷的选项既可以是工作站垃圾回收又可以是服务器垃圾回收。 对于两个以上处理器的计算机，服务器垃圾回收应该是最快捷的选项。
从MSDN上并没有太多讲述Server GC把发挥的作用，最明确一点就是可以使用多处理器对GC进行快捷处理，至于这种配置在服务程序中具体能发挥多少作用呢没有一个具体的指标性东西。然而以于asp.net mvc这些项目默认都会编译成ServerGC模式并不需要配置，而我们自己写的Console程序则不是，需要根据情况自行配置。
修改后的运行效果
于是把这配置信息复制到测试程序上，结果一跑整体的效果才出来，这个时候服务基本可以跑满所有核资源；RPS从原来的最大14万提高到24万,在压测1000万请求的过程保持稳定。由于对GC了解不是很深入，初步猜想由于默认是单线程处理GC，这样会导致所有线程都会卡在GC处理上；即使你加大线程池数量或加大并发也不会从根据上解决问题，只会让并发处理延时加大！ 当在多核开启GC Server的情况上GC就不会卡在一个线程上由多核的线程来完成，由于GC处理不会卡在一个线程，所以资源能够完全发挥出来提高并发处理能力。
程序配置Server GC
项目属性配置里是没有Server GC这项设置，网上有资料说在app.config中进行配置，但这个配置对dotnet core程序是无效的。后来在MSDN找到资料需要手动编辑csproj 文件在PropertyGroup中添加相关内容.
<PropertyGroup>
<ServerGarbageCollection>true</ServerGarbageCollection>
</PropertyGroup>