1. 通過增加復雜性解決一個問題，會產生全新系統失效方式的風險

2. 多線程技術使應用程序服務器具有足夠的容量擴展能力，來滿足Web上最大站點的需求

2.1. 產生并發錯誤的可能性

3. 服務器的進程正在運行

3.1. 并不能幫助用戶完成工作

3.2. 模擬客戶端使用系統的體驗，與真實用戶是相同的

3.3. 該客戶端無法進行合成事務，那么無論服務器進程是否正在運行，都可判斷系統存在問題

3.4. 使用度量指標快速揭示問題，不必非要等到系統告警

3.5. 用外部監控補充內部監控

3.5.1. “系統崩潰”和“系統停止響應”之間區別

4. 多線程問題

4.1. 錯誤條件和異常會產生太多的排列組合，難以進行全面徹底的測試

4.2. 意外的交互可能會在先前安全的代碼中引入問題

4.3. 運行時機至關重要，應用程序停止響應的概率會隨著并發請求數量的增加而增加

4.4. 開發工程師從來不會為了測試而向應用程序發送10000個并發請求

5. 謹慎使用緩存

5.1. 濫用緩存可能造成新問題

5.2. 緩存能有力地解決性能問題

5.2.1. 減少數據庫服務器的負載

5.2.2. 縮短響應時間

5.2.2.1. 將其控制在不進行緩存所用時間以內

5.3. 所有應用程序級別緩存的最大內存使用量，應該是可配置的

5.3.1. 不限制最大內存使用量的緩存，最終會消耗系統的可用內存

5.4. 緩存消耗了其他任務所需的內存，實際上會導致系統嚴重降速

5.5. 無論緩存上設置了多大的內存，都需要監視緩存項的命中率

5.5.1. 檢查是否大多數緩存項已被使用

5.5.2. 命中率非常低，那么緩存就不會獲得任何性能優化

5.5.3. 實際上還可能比不使用緩存更慢

5.6. 把數據保存在緩存中，其實是一次投注

5.6.1. 押寶“一次生成數據的成本，加上散列和查找數據的成本，不超過每次需要生成該數據時的所需成本”

5.7. 如果一個特定的緩存對象，在服務器的生命周期中只使用一次，那么緩存它就沒有任何意義

5.8. 避免緩存特別容易生成的數據

5.9. 通過使用弱引用持有緩存項本身構建緩存

5.10. 任何緩存都存在數據過時的風險

5.10.1. 每個緩存都應該有一個失效策略，當其源數據發生變更時，能夠在緩存中刪除緩存項

6. 選擇精心設計并經過驗證的代碼庫

6.1. 構造可靠、安全、高性能的連接池，總是會比想象的困難許多

6.2. 所有的問題都可能潛伏在第三方代碼的陰影中

6.2.1. 相比閉源程序庫，更喜歡開源程序庫

6.3. 程序庫都是導致線程阻塞的源頭

6.3.1. 如果是開源庫，那么就可能有時間、技能和資源來查找和修復這些問題

6.4. 集成點附近經常出現線程阻塞

6.4.1. 線程阻塞和緩慢響應會創建一個正反饋循環，將小問題放大到系統的完全失效

6.5. 線程阻塞反模式是大多數系統失效的直接原因

6.5.1. 線程阻塞反模式會導致同層連累反應和層疊失效

6.5.2. 常見的系統逐漸變慢和服務器停止響應

7. 使用超時模式進行保護

7.1. 雖然無法證明代碼不會發生死鎖，但可以確保死鎖不會一直持續下去

7.2. 避免函數調用中的無限等待，使用需要超時參數的函數版本

7.3. 即使意味著需要更多的錯誤處理代碼，調用過程中也要始終使用超時模式