為了驗證 docker swarm 在高並發下的性能問題，周一我們發布了使用 docker-compose 部署的 .net core 版博客站點（博文鏈接），但由於有1行代碼請求后端 web api 時沒有使用緩存，結果造成大量 web api 請求發向跑后端服務的集群，悲劇的是這個集群是用 docker swarm 部署的，請求是用 nginx 容器轉發的，結果壓垮了 nginx ，大量后端請求 502 ，被迫回退至 windows + .net framework 版博客系統。
使用 docker-compose 部署沒有出現高並發下響應速度極不穩定的性能問題，以及后端 docker swarm 集群被大量請求壓垮，已經基本驗證了 docker swarm 的眼高手低，無法勝任高並發的場景。
在准備改用 k8s 部署之前，我們決定進行一個最直截了當的對比，用同樣配置的 windows 服務器部署 .net core 版博客系統（同“窗”就是指這個），對比一下 .net core vs .net framework 的性能，看看是否真的是“青出於藍而勝於藍”？
直接在部署 .net framework 博客系統的 windows 服務器上安裝 .net core sdk 並部署 .net core 版博客系統，“同窗”名副其實，一點不參假，不僅用的都是“Windows Server 2016 數據中心版 64位英文版”，而且系統環境配置都一樣。asp.net core 站點部署方式使用的是 IIS InProcess Hosting ：
<AspNetCoreHostingModel>InProcess</AspNetCoreHostingModel>
在 Startup 的 ConfigureServices 中允許 IIS InProcess Hosting 的同步 IO
services.Configure<IISServerOptions>(options => { options.AllowSynchronousIO = true; });
不然會出現錯誤
Synchronous operations are disallowed. Call WriteAsync or set AllowSynchronousIO to true instead
另外，之前發布后提交評論速度慢是代碼的問題，.net core 中沒有 .net framework 中的 HostingEnvironment.QueueBackgroundWorkItem ，遷移時我們偷懶了，沒有把提交評論的一些操作放到隊列中處理。今天我們改進了代碼，用 Coravel 的隊列功能實現了，現在提交速度有了明顯的改善。
Windows 上的 .net core 版博客站點已於 18: 15 左右發布上線，它的表現如何，請看明天上午下午訪問高峰的演出。
發布后立即發現 .net core 版的 CPU 消耗明顯高於 .net framework 版
發布前 .net framework 版用了4台4核8G的服務器，CPU 占用情況如下
發布后 .net core 版用了5台4核8G的服務器，且訪問量更低，CPU 占用情況如下
這個 CPU 占用異常高的問題估計我們寫的代碼有關，我們會進一步排查。
更新
18:45 左右，加了1台服務器，現在是6台服務器。
19:10 左右，由於CPU占用問題，暫時下線。6台服務器訪問量更低時，CPU 波動很大，見下圖。
22:26 ，CPU 占用異常高問題目前排查下來最大的嫌疑是 EnyimMemcachedCore ，明天會進行驗證。
8:22 ，
相關博文：