1、數據庫方面
1.1、配置連接池：合理設置連接池的保有量，增長量，連接保持時長（正確評估系統的併發量，高峯期訪問量，減少連接創建與銷燬的開銷）
1.2、優化表設計：對高頻率連接查詢進行數據冗餘（尤其是數據量極大的表、將需要連接查詢的主表字段冗餘至從表），以單表查詢的方式提供高效查詢（以存儲空間換查詢效率）
2、應用服務器方面
2.1、緩存配置：將經常訪問且又極少變化的數據進行緩存處理（從而減少對數據庫的訪問），直接提供響應和結果返回。（可以直接用HashMap，也可以使用緩存框架EhCache等）
2.2、日誌記錄：去除控制檯打印和error以下的日誌輸出（僅記錄error級別的日誌到日誌文件中。），以減輕IO與服務器系統資源。
2.3、每日檢查錯誤日誌，解決錯誤的問題，保證系統穩定運行無可控異常。
2.4、足夠的服務器內存配置（監控系統內存使用情況，合理增加堆內存的配置，減少cg。）
3、客戶端方面
3.1、利用客戶端緩存：如：js、css文件緩存，ajax請求緩存等，減少客戶端對服務器的請求量（對js、css等進行參數變更設置，以解決js、css文件的版本更迭 -- 參數不一樣，客戶端則會認爲是不同的文件，則會進行重新下載（訪問服務器）。-- 這裏是很多新手程序員遇到緩存的問題，自己明明改了js的方法，但是爲什麼一直不生效，需要進行一次瀏覽器清理緩存才能生效。但是並不是所有用戶都會自己清理緩存，我們也不應該要求用戶手動清理緩存。）
3.2、排序分組等複雜算法：把無需保密的或其有權限訪問的數據運算、處理加工放至客戶端進行（如：複雜的多規則排序，分組等），這樣可以減輕服務器的壓力，將其分攤至客戶端，但相對增加了客戶端的要求。（這種方式可以明顯減少高併發，高訪問量的服務壓力，例：設運行需要消耗服務器X個資源，100個客戶同時請求服務器，如果在服務器端運行則需要服務器提供100*X個資源。如果在客戶端，則由每個客戶端獨自提供X個資源。只要客戶端普遍都能支付得起X個資源，那麼系統無論是100個客戶還是10000個用戶，那麼訪問都能穩定執行和響應。而放在服務端，則隨着客戶量的增加，系統很快就會到達瓶頸）
4、網絡傳輸方面
4.1、數據庫數據傳輸：去除沒必要的字段查詢，使數據庫僅返回有用的數據結構（列）。這樣可以減少數據庫服務器的網絡帶寬壓力，同時也會減少數據庫對磁盤的讀取量（IO量），同時也會減少數據庫對響應數據的緩存量（數據庫會對請求結果進行緩存，在遇到相同的sql查詢時，直接將內存中的結果返回給請求者，那麼去除了沒必要的字段，則會節省不少內存空間，也就減少的數據庫緩存的清理頻率。）
4.2、服務器數據傳輸：去除沒必要的字段內容響應，使服務器僅返回有用的數據結構給客戶端（Vo）。這樣可以減少應用服務器的網絡帶寬壓力，（如果是特意的封裝Vo，則會增加服務器的資源開銷，在這個矛盾之間，就看系統的併發量和訪問量以及瓶頸的所在 -- 即，到底是網絡導致了服務能力到達了瓶頸還是應用服務器CPU/內存資源無法提供更高的服務能力）(但，一般數據庫查詢時已經優化了字段傳輸，則此處的傳輸就不會需要太多的優化。)
5、其他
5.1、優質代碼和SQL：這是對應工程師（數據庫工程師、後端工程師、前端工程師）自身的經驗與技能強度問題。
5.2、優秀的架構與佈局：這是架構師自身的經驗與技能強度問題。
