接下來進行集羣的壓測，配置跟單機的一樣，一臺數據庫+redis+mq，兩臺應用，一臺nginx。
沒有任何優化的情況下：
可以看出數據庫壓力很大，nginx壓力很大，而且有很多錯誤連接
優化一下數據庫（同單機）：
tps變高了，訪問500也變少了
再優化一下tomcat並建立長連接（同單機）：
可以看到，和單機一樣，建立長連接後性能反而下降，後面對這個進行研究。
ngxin建立長連接：
有所提升，相對的應用層消耗有所減少。
接下來加入redis：
由於1000個線程現在有點少了，沒跑起來就結束了，所以增加至3000個，20次：
tps又有了提升，這個截圖是峯值，平均下來大概兩千多。現在的瓶頸看起來是nginx，這個後面再研究。
使用guava cache存儲本地緩存+redis二級緩存：
把應用服務器配置改爲4核8G：
從結果上看，內存緩存的性能比redis還差。壓力全在應用服務器上，而沒有分散在redis上，所以雖然避免了網絡通信產生的損耗，但是對於應用服務器的性能還是有考驗的，因此是否用、怎麼用內存緩存還是需要權衡的。
nginx share dic：
使用nginx的共享內存字典，性能又提高了不少。當然缺點也是一樣，緩存沒法更新，並且壓力全在nginx服務器上。
nginx 使用lua調用redis：
由於網絡通信的損耗，所以性能沒有nginx好，但是對於管理來說，是更好的。
至此，動態資源的讀操作的測試就到這了。靜態資源及頁面靜態化和cdn加速很簡單，這裏就不測了。
接下來進行總結一下，首先在單機情況下，加索引的查詢速度會快不少，理論上主鍵索引＞唯一索引＞非唯一索引＞無索引，但在測試的時候主鍵索引的查詢速度小於非唯一索引，這裏需要研究。
通過增加soket連接數、數據庫緩存等方面可以使系統性能略微提高，而增加長連接後在測試中卻降低了，這裏關於Http11NioProtocol也需要研究。
併發條件下，優化數據庫配置可以使tps提高不少，而增加長連接後也降低了。
假如redis，數據庫的壓力減小，使性能進一步提高，而如果使用本地緩存+redis的多級緩存結構，對於應用服務器的性能就有了考驗，機器配置的高低會影響速度。
使用nginx的share dic，由於可以直接從nginx緩存中讀取，不需要再經過應用服務器和數據庫，所以速度大大提高了，但是由於內存式緩存的侷限性，所以可以結合redis，但由於網絡通信損耗，所以性能沒有直接在nginx中快，當然這也考驗nginx服務器的機器性能了。