Web前端性能優化
Web前端指網站業務邏輯之前的部分，包括：
1.瀏覽器加載
2.網站視圖模型
3.圖片服務
4.CDN服務等
主要優化手段有優化瀏覽器訪問，使用反向代理，CDN等。
1.瀏覽器訪問優化
(1)減少http請求
HTTP協議是無狀態的應用層協議，意味著每次HTTP請求都需要簡歷通信鏈路，進行數據傳輸，而在服務器端，每個HTTP都需要啟動獨立的線程去處理，這些通信和服務的開銷都很昂貴，減少HTTP請求的數目可有效提高訪問性能。
減少HTTP請求的主要手段是:
- 合併CSS，以及壓縮CSS大小
- 合併JavaScript，以及壓縮JS大小
- 合併圖片
將瀏覽器一次訪問需要的JavaScript,CSS合併成一個文件，這樣瀏覽器就只需要一次請求。多張圖片合併成一張，如果每張圖片都有不同的超鏈接，可通過CSS偏移響應鼠標點擊操作，構造不同的URL。
(2)使用瀏覽器緩存
對一個網站而言，CSS,JavaScript,Logo,圖標等這些靜態資源文件更新的頻率都比較低，而這些文件又幾乎是每次HTTP請求都需要的，如果將這些文件緩存在瀏覽器中，可以極好地改善性能。通過設置HTTP頭中Cache-Control和Expires屬性，可設定瀏覽器緩存，緩存時間可以是數天甚至是幾個月。有時候，靜態資源文件變化需要及時應用到客戶端瀏覽器，這種情況可以通過改變文件名實現，比如一般會在JavaScript後面加上一個版本號，使瀏覽器刷新修改的文件。
(3)啟用壓縮
在服務器端對文件進行壓縮，在瀏覽器端對文件解壓縮，可有效較少通信傳輸的數據量。文本文件的壓縮效率科大80%以上。
(4)CSS放在頁面最上面，JavaScript放在頁面最下面
瀏覽器會在下載完全部CSS之後對整個頁面進行渲染，因此最好的做法是將CSS放在頁面最上面，讓瀏覽器儘快下載CSS。JS則想法，瀏覽器在加載JS後立即執行，有可能會阻塞整個頁面，造成頁面顯示緩慢，因此JS最好放在頁面最下面。
(5)減少Cookie傳輸
一方面，Cookie包含在每次請求和響應中，太大的Cookie會嚴重影響數據傳輸，因此哪些數據需要寫入Cookie需要慎重考慮，儘量減少Cookie中傳輸的數據量。另一方面，對於某些靜態資源的訪問，如CSS,JS等，發送Cookie沒有意義，可以考慮靜態資源使用獨立域名訪問，避免請求靜態資源時發送Cookie，減少Cookie傳輸的次數。
2.CDN加速
CDN(Content Distribute Network,內存分發網絡)的本質上仍然是一個緩存，而且將數據緩存在離用戶最近的地方，是用戶以最快速度獲取數據，即所謂網絡訪問第一跳。
CDN一般緩存的是靜態資源，如圖片，文件，CSS，Script腳本，靜態網頁等，但是這些文件訪問頻率很高，將其緩存在CDN可極大改善網頁的打開速度。
3.反向代理
傳統代理服務器位於瀏覽器一側，代理瀏覽器將HTTP請求發送到互聯網上，而反向代理服務器位於網站機房一側，代理網站Web服務器接收HTTP請求。和傳統代理服務器可以保護瀏覽器安全一樣，反向代理服務器也具有保護網站安全的作用，來自互聯網的訪問請求必須經過代理服務器，相當於在Web服務器和可能的網絡攻擊之間建立了一個屏障。
除了安全功能，代理服務器也可以通過配置緩存功能加速Web請求，當用戶第一次訪問靜態內容的時候，靜態內容就被緩存在反向代理服務器上，這樣當其他用戶訪問該靜態內容的時候，就可以直接從反向代理服務器返回，加速Web請求響應速度，減輕服務器負載要。
應用服務器性能優化
應用服務器就是處理網站業務的服務器，網站的業務代碼都部署在這裡，是網站開發最複雜，變化最多的地方，優化手段主要有緩存、集群和異步等。
網站性能優化第一定律：優先考慮使用緩存優化性能。
緩存的本質是一個內存Hash表，網站應用中，數據緩存以一對Key,Value的形式存儲在內存Hash表中。緩存主要用來存放那些讀寫比很高、很少變化的數據。
二八定律：80%的訪問落在20%的數據上
使用緩存需要注意的問題：
- 把頻繁修改的數據放入緩存。容易出現數據寫入緩存後，應用還來不及讀取緩存，數據就已經失效的情形，徒增系統負擔。一般來說，數據的讀寫比在2:1以上，緩存才有意義。
- 沒有熱點的訪問。 緩存使用的內存資源非常寶貴，只能將最新訪問的數據緩存起來，而把歷史數據清理出緩存。即緩存資源應該留給20%的熱點數據。
- 數據不一致與髒讀。 一般會對緩存設置失效時間，超過失效時間，就要從數據庫重新加載。因此應用要忍受一定時間的數據不一致。另一種策略是數據更新時立即更新緩存，不過這也會帶來更多的系統開銷和事務一致性的問題。
- 緩存可用性。 業務發展到一定階段時，緩存會承擔大部分數據訪問的壓力，數據庫已經習慣了有緩存的日子，所以當緩存服務器崩潰時，數據庫會因為完全不能承受如此大的壓力而宕機，進而導致整個網站不可用。這種情況被稱作緩存雪崩，發生這種故障，甚至不能簡單地重啟緩存服務器和數據庫服務器來恢復網站訪問。 解決方式：1、緩存熱備（當某臺服務器宕機時，將緩存訪問切換到熱備服務器上。）；2、緩存服務器集群。
- 緩存預熱。 緩存中存放的是熱點數據，熱點數據是緩存系統用LRU對不斷訪問的數據篩選出來的，這個過程需要較長的時間。新啟動的緩存系統沒有任何數據，此時系統的性能和數據庫負載都不太好。因此可以選擇在啟動緩存是就把熱點數據預加載好。
- 緩存穿透。 因為不恰當的業務或惡意攻擊，持續高併發地訪問某一個不存在的數據，如果緩存不保存該數據，就會有大量的請求壓力落在數據庫上。簡單的解決方式是把請求的不存在的數據也放進緩存，其value是null。
對應可以考慮的分佈式緩存有memcached、redis，降低對數據庫的讀操作。
數據庫SQL性能優化
最後就是考慮數據庫端的性能優化，如果訪問量巨大，除了sql優化外，還會涉及到分庫分表、讀寫分離、利用數據庫中間件來解決(下面架構師系列有講)，這裡就不再重複。
1.對查詢進行優化，要儘量避免全表掃描，首先應考慮在 where 及 order by 涉及的列上建立索引。
2.應儘量避免在 where 子句中對字段進行 null 值判斷，否則將導致引擎放棄使用索引而進行全表掃描，如：
select id from t where num is null
3.應儘量避免在 where 子句中使用 != 或 <> 操作符，否則將引擎放棄使用索引而進行全表掃描。
4.應儘量避免在 where 子句中使用 or 來連接條件，如果一個字段有索引，一個字段沒有索引，將導致引擎放棄使用索引而進行全表掃描。
5.in和 not in 也要慎用，否則會導致全表掃描，如：
select id from t where num in(1,2,3)
對於連續的數值，能用 between就不要用 in 了：
select id from t where num between 1 and 3
6.對於多張大數據量（這裡幾百條就算大了）的表JOIN，要先分頁再JOIN，否則邏輯讀會很高。
7.索引並不是越多越好，索引固然可以提高相應的 select 的效率，但同時也降低了 insert 及 update 的效率，因為 insert 或 update 時有可能會重建索引，所以怎樣建索引需要慎重考慮，視具體情況而定。一個表的索引數最好不要超過6個，若太多則應考慮一些不常使用到的列上建的索引是否有 必要。
8.儘量使用數字型字段，若只含數值信息的字段儘量不要設計為字符型，這會降低查詢和連接的性能，並會增加存儲開銷。這是因為引擎在處理查詢和連 接時會逐個比較字符串中每一個字符，而對於數字型而言只需要比較一次就夠了。
9.儘量避免向客戶端返回大數據量，若數據量過大，應該考慮相應需求是否合理。
10.儘量避免大事務操作，提高系統併發能力。
閱讀更多 互聯網進階學院 的文章
