除了前面文章讲的性能测试，我们还需要调研哪些东西呢？要满足那么大的并发的情况下我们肯定要去做集群部署。我们作为专业的非功能测试人员，需要了解web服务的可用性，什么是web服务的可用性？我们是不是要做web服务的集群部署、Apache的集群部署，Nginx的集群部署、硬件集群部署等等方面。
接下来我们看到了Token、APP的可用性测试，所谓的可用性也就是weblogic集群部署，他的部署方式是什么样的，也是我们需要去关注考虑的的。
接下来我们需要考虑的是什么，最重要的一点是数据不能丢，所以要做数据库的集群可用性测试。一主多从，当一个主机坏掉了，会不会自动切换到某一个从库，会变成主库，当坏掉的主库修好之后，是不是还原成主库了，之前变成主库的从库，是不是自动切换成从库了呢？
各方面的架构设计我们是不是有测试到位？这些在测试的过程中我们去做持续高并发的情况去模拟故障。
往往对软件的集群部署过程中还需要对硬件的集群部署，像刚才说的硬件的可用性，别用了10台服务器，有些开机2天就坏了。我们模拟一段时间看看，模拟7*24小时硬件会不会出问题，正常情况下硬件厂商都有这些测试，但是硬件厂商都是模拟自己的，没有结合我们的业务的情形下去测试，所以我们需要针对我们具体的业务去模拟真实的业务场景。
通过Loadrunner或者Jmeter去模拟高并发过程中，硬件的吞吐量。像网卡，吞吐量怎么样？我们的网卡和带宽大家都知道，百兆网卡，其实可用的没有那么多。现在是千兆网卡时代，能充分被利用到的网卡流量有多大呢？这些硬件服务的可用性我们要去测试看看。
多张网卡的分发过程中也是需要去做测试的。前段时间我就帮一些企业去做以T为单位的流量网卡的测试，测试并发的过程中流量是不是均衡。
再有一点ES服务器，大数据的报表展现，把数据写在内存里面，能够快速地展现出来，这个时候一个页面可能能够展示好几千个字段，如果换成普通的架构，可能就展现不了，换成ES数据库就可以实现。但是再怎么展现怎么快，总是人设计出来的，只要是人设计出来的就容易出问题。我们就需要去做测试确保不出问题。
前端页面正常访问，就需要做各种集群部署，集群部署过程中，Elasticsearch能访问在于内存访问，也在于内存数据库，从内存数据库访问出数据来。内存数据库再从二维表、DB数据库中再去把数据拿出来，每个方面都有，形成了一个7*24小时的闭环，能持续一直使用，响应也很快。
以前的258原则现在变成了123原则。4G、5G的到来，并发越来越高，全世界信息的流通越来越发达。
