場景：
0、原始所有數據庫均爲access，爲了優化速度，將容量佔比最大的文章表升級爲mssql數據庫，並且遷移到了另一臺服務器；
1、程序與mssql數據庫不在同一內網；
2、連接一次約200-400ms，程序首頁進行了6次連接，導致頁面響應時間長達2.2-2.6s；
問題分析：
將程序頁面複製到mssql服務器，通過ip連接自身數據庫6次，響應時間僅爲200-400ms。將程序頁面複製到其他web服務器，響應時間仍爲2s+。說明與服務器性能無關，主要爲網絡問題。
單次響應時間長達200-400ms，應爲請求通過各網絡節點+web服務器防火牆、安全組出/入+sql服務器防火牆、安全組出/入時，累計產生的延遲。同時，每次請求都會重複這些步驟，最終導致響應總時間長達2s+。
解決方案：
將首頁需要連接的6個模塊內容的數據，在後臺數據提交階段，就同時保存到同服務器的專用access表裏(正則表達式也在此環節應用，首頁直接讀取結果，不用每次訪問都執行一次。此優化也能提升1s)。該表，僅保存首頁需要讀取的數據字段及內容，如6個模塊的標題、mssql數據庫的id、添加時間、及部分過濾後的content。
由於僅保存小部分剛需內容，所以該表數據庫很小，響應速度很快。且該表內數據，僅最新的幾條是實際使用。其餘過期數據爲冗餘數據，有必要時，可全部清楚進一步提升響應速度。
總結：
該解決方案雖有點怪異，但針對該特殊場景，仍具有一定價值。缺點是增加了程序的複雜程度。