同「窗」的較量：部署在 Windows 上的 .NET Core 版博客站點發布上線（已暫時下線）

爲了驗證 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 ，

相關博文：

• 【故障公告】發佈 .NET Core 版博客站點引發大量 500 錯誤
• 【網站公告】.NET Core 版博客站點第二次發佈嘗試
• 暴風雨中的 online : .NET Core 版博客站點遭遇的高併發問題進展
• Powered by .NET Core 進展：驗證高併發性能問題嫌疑犯 docker swarm