接下来进行集群的压测，配置跟单机的一样，一台数据库+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服务器的机器性能了。
