2016年12月，蘋果新通知必須HTTPS。 原本我們的項目運行在windows server 2008R2(內存32G cpu 16 帶寬 10M)下面，是沒有任何問題的，已經正常運行半年有餘了。我們服務器有2個項目 暫時叫做項目A B。升級HTTPS 2個項目都需要 IIS7.5 是無法做到的 ，必須支持SNI 纔可以。然後着手升級阿里雲服務器，升級到最新版本windows server 2012R2 IIS8.5,所有配置保持不變，硬盤有SSD 換成了高效雲。然後問題開始出現了。
平常運行是沒有問題的，我們每個週三都有一個秒殺活動。每個週三下午2點30分鐘準時 400或者200個物品一元搶購，然後週三開始癱瘓了。 這個問題是有歷史淵源的。剛入到這個公司接受項目 這個項目 是Nhibernate+webform+webservice 做的，是一個比較老的項目，中間還穿插了幾個維護人自己的技術。網站沒什麼流量 也就運行着，然後公司開始上線秒殺活動，根本無法運行，日誌測試下 發現Nhibernate 根本數據處理太慢 ，高併發 下 CPU直接爆了，這個CPU 都爆了 肯定代碼問題了。然後着手換訂單流程 和主頁面的代碼，換框架是來不及了 然後 就用ado.net 重寫了，順便加入了緩存機制。
說下這裏的緩存機制吧，但是想的是reids 來做的，也比較潮流 口碑比較好。但是當時項目着急上線 來不及給你實驗了 就用了 最簡單的硬盤txt 來緩存，我們網站的在線人數 是足夠的。
問題解決，秒殺活動也就正常了。很輕鬆 換下數據獲取方式 加上緩存。
服務器升級後問題又來了，老毛病又犯了。但是這次不一樣 CPU 內存 帶寬 一切正常，但是網站卡死，但是同服務器的網站B 正常運行。然後自己想想 應該不是代碼的問題，畢竟成功運行了這麼久了，服務器應該也沒有問題 網站B 都可以正常運行，應該是程序池的原因。 開始排查服務器 研究IIS8.5，把IIS8.5的發佈視頻都給看了，然後在事件查看器→windows 日誌→應用程序 裏面 查看到錯誤一句英文：The state server has closed an expired TCP/IP connection. The IP address of the client is 127.0.0.1. The expired Read operation began at 01/04/2017 16:36:57。網上查下狀態服務連接關閉了，轉到服務看了下 asp.net state service 正常運行啊。思前顧後 也就秒殺這個時間段出現了這一個錯誤，然後把 狀態服務 直接存到了 數據庫，具體方法可以百度。以爲問題解決了 真是so young 啊，沒有壓力測試下 就上線了，第二週又掛了 這次沒有報那句英文錯誤了，但是還是卡死。頭大了，臨近年關你給我整這出，還要不要讓我過年了啊。這次直接開始壓力測試，但是網上的壓力測試大多數都是壓整個服務器起的 和我們出現的情況不太相同啊，中間找了很多的資料，看的感覺最像的就是博客園的黑色30秒事件 具體可以看連接http://www.cnblogs.com/cmt/p/3682642.html，博客園寫了好幾篇文章 大家可以看看，說的非常細緻。也根據他們提供的解決方案
<processModel enable="true" requestQueueLimit="5000" maxWorkerThreads="100" maxIoThreads="100" minWorkerThreads="50" minIoThreads="50"/>
對machine.config（位於C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config）經行了修改。 然後進行壓力測試（我們用的壓力測試工具是WebPerformanceTest）發現某些頁面 某些接口 是沒有問題，有些接口有些頁面 進行壓力測試項目就開始卡了（我們 壓力測試 進行是 本機 和一臺測試服務器同時進行 併發用戶數 每臺是1000，一臺進行10分鐘壓力測試
另一臺是10000個請求），然後查看 性能測試頁面 發現requestd current 爆了，requestd queued 沒有了，在沒有進行machine.cofig修改時候 requsted queued 會很大 但是不至於爆了。說明這個設置有效果，但是還是卡 還是沒有根本的解決問題啊。後來把state service 又還原到以前的內存讀取。
再次分析阿里雲，發現在壓力測試的時候 阿里雲的IO 網絡 帶寬會到峯值 也就達到了頂值，會不會是因爲 緩存寫在硬盤導致的高效雲太差勁 沒有SSD好。開始倔起來了啊，直接打電話找阿里雲 問問題 人家小姑娘那裏懂這些問題啊， 提交工單。。。。尼瑪 提交工單，問題描述下提交過去。阿里雲那邊的答覆是：二者相同，在XXX功能上面 高效雲比SSD的好，順便幫我們查看了說 帶寬不夠。 這個怎麼可能啊 10M 帶寬 這纔多少人啊。 （後來我們通過IIS 日誌分析請求 用的是秋式網站日誌分析器 當天的請求 才 60W個，秒殺活動 當時的請求也就 2.30 到3.00的請求 才 25W 多點），靠阿里雲是不行了，自己動腦豐衣足食。影響帶寬，影響IO 會有那些了。圖片下載，硬盤寫緩存。 一個一個來 我們對圖片的讀取經行了一次壓力測試 發現沒有問題啊。這個可以排除了，剩下就是 緩存寫入硬盤了。
換緩存的讀寫方式，棄掉硬盤讀取 緩存redis，具體怎麼讀寫 就是網上最簡單的，我們也就是對幾個頻繁頁面進行緩存，沒什麼技術可言。壓力測試 還是掛，但是 又換了展現方式了，我緩存是 接口讀寫的json ，壓力測試PC 網站。我沒有把所有的都緩存。誒 繼續想。
又把問題轉移到代碼上面 在次進行日誌測試，發現某些壓力測試卡的接口 和頁面 居然的底層數據庫還有些 Nhibernate 獲取數據，Nhibernate +sql 的獲取方式，真是高估了Nhbienate了，繼續換成 ADO.NET。 然後在網上又找到了一篇文章關於設置IIS 支持高併發的文章，我寫在上一篇的文章中，具體可以自己查閱。然後壓力測試 OK了。每個接口都壓了下 發現都可以了。 具體解決方案 我也不太清楚了 畢竟改了太多設置，代碼也換了不少東西。下面我會總結 我修改 的地方。前面大多數都是自己的抱怨，可以直接轉移到 終極解決方案。
中途一個小插曲，沒想到 這麼點用戶的項目 都給我整上 僞分佈式。我將 IOS pc android 進行了分開部署，這樣 就算卡了 也就卡了單方面 ，其他端還是可以參與活動，這個當作備胎方案實施吧。不怕一萬就怕萬一啊，領導再次說搶不了 今年就別想提加工資了。 這個也是大項目的一個 基本部署， 接口 登錄 支付 PC端 靜態文件 數據庫 分開部署。
終極解決方案：1.修改machine.config
2.根據我上一篇隨筆 修改了IIS 配置 和電腦TCP/TP的連接數
3.硬盤緩存換成redis緩存
4.將項目中殘餘的Nbibienate+sql 全部換成 ado.net
5. IOS PC Android分開部署
具體哪一步解決了我的問題 我也不太清楚，