以前經常在網上看到web網站設計需要注意事項。
但實際操作性很低，因爲他們只是給了一個結論，如果自己稍微有點想法，就很難去相信這些結論。
出於眼見爲實的目的，正好在一個項目裏，我們需要對項目做大壓力併發測試。。。
1、ab只能是初步的做初步的壓力測試。
很簡單的道理。。我們用ab能壓到最高5萬的併發請求。服務器也沒啥事。但是，這是真的嗎？
於是我們開始監控服務器的各項資源。發現僅僅是CPU和進程有了變化。其他的IO和網絡指標占用極其低下。換句話說，AB僅僅只是對服務端做了請求。html等元素並沒有在ab性能測試裏面。
2、網絡流量是最大的瓶頸
這個網上很多人都說了。。我還是動手驗證了一下。
100M帶寬下，最高理論峯值是12.5M。實際峯值只有11M左右。偶爾能上12.5M。這是服務器監控的結論。客戶端網絡壓根就沒滿（我用了5臺客戶機）。爲什麼會這樣？簡單做了一個小測試。不壓任何東西。就壓一個單獨的圖片。70k左右。200用戶的時候網絡出現峯值11.5M。這是什麼情況呢？再看看每秒事務數，160次/s.正好11M左右。也就是說100M帶寬。你的服務器同時只能傳輸出160張圖片。這個就很容易類比了。如果你的頁面需要70K的資源（html，圖片，等等）。在百兆環境下，只能有160個人的併發能力。這不是服務器限制的。。網絡的限制非常大。不要以爲160併發很小了。按現在測試中的公式。160併發。大概等於2000人同時在線的情況。這個同時在線，是指每個人手抽經不停的點鏈接。。所以，在高併發的需求下，儘可能的降低頁面大小。確實能夠帶來更多的併發處理能力。
舉個例子。。gzip開啓能減少50%以上的網絡傳輸量。雖然帶來cpu的負載過多。但是，在32核的服務器下，這都是浮雲。但是假設是在100M帶寬下，就能多帶來一半的併發用戶。1000M就更多了。。如果再加上千兆分流等其他手段。服務器的併發能力就能得到最大的發揮。
但如果不注意這些。我們測試了很多場景，發現網絡流量始終是最大的瓶頸，壓根就別想把服務器的最大處理能力發揮出來。
3、圖片和附件從應用服務器分離出來是個好主意
這個的理由同上，網絡流量有瓶頸，並且圖片和附件是有IO的。放在應用服務器裏面，影響應用服務器的處理能力。
4、應用中有影響，但不會是最大的影響
我們是用的php，但我們發現就算你代碼再爛。最多耗點內存和cpu。實際的併發處理能力並不會有太大的影響。如果加入文件緩存。會有很大的io損耗，可是如果圖片和附件在同一臺服務器上。加入文件緩存帶來的效率提升並不明顯。當然，這些都是建立在高併發的情況下。
有一種緩存的處理方式，就是把緩存和內存做個映射。這樣就降低了IO損耗。帶來很好的效率提升。
優化數據庫查詢會好很多。。。。這個。因爲我們的測試腳本中數據庫查詢本來就是最優的。。沒啥可以測得。所以暫不做評價
