前阵子跟7D Group里的人商量了一下，添加了个新的云服务器来做研究用。
因为性能相关的东西如果不动手操作的话，是很难说服人的。
也许有人说，你都已经云了，还要docker干吗？其实是为了，练着玩。
有人说docker会改变测试的一些东西。确实如果images做好了会省点事。
我们现在有的环境如下：
有nginx / tomcat / redis / mysql。并且也随便从网上搂了一个springboot小应用，以做脚本之类的。从完整性上来说是够了。
按我之前写的benchmark结果来看，内网带宽500M以上，应该是够用了。不过服务端的主机不够，在当前的应用下能跑出来个200TPS就不错了。
nginx将response time和upstream response timer配置上了。
tomcat将request time和response timer配置上了。通过这两个数据，就可以知道时间消耗在哪一层了。
redis还好，毕竟这个压力也太小了。
只有MySQL可能会压力大一点，不过现在是个好的开始。
我们要在这样的环境下把瓶颈点分析出来，再看后面是要加机器还是要改配置。
老早以前在做性能测试的时候，就有人跟我说，把环境降到最低，看应用的性能表现。我当时说其实没有必要。那现在呢。我还是要说，如果要看软件的问题，根本不用降硬件环境。（可见我这些年都这么固执呀。）
因为要想分析软件的问题，在任何环境下都是可以分析的，配置高了会更好。而我现在在这个简单的云环境里做测试，是因为实在是不想多花钱。
那既然这么说，如何考虑硬件环境呢？
其实要想在性能测试中考虑硬件对结果的影响，我们必须分析另一个东西，那就是生产环境。如果不做测试环境和生产环境中的硬件比对的话，在测试环境中考虑硬件就没有多大价值。
性能容量的结果应该给线上环境做参考，而不是测一下而已。这个数据要足够精确。如果场景做得好的话，大概会在5%左右的误差。那就牛逼了。
如果生产环境的性能表现（比如说单实例的TPS）和测试报告中的差别太大的话。那这个性能结果可以说毫无意义。
要想根据测试环境的硬件给生产环境做参考，无非有两种方式。
一种是拿一样的硬件来测试；
第二种是做相应的评估换算。之前我看到过一些资料中有想进行这个换算的，但是大部分是以扯蛋的态度写的。
我建议我觉得可靠的方法，那就是先对测试环境和生产环境的硬件做benchmark，然后再做benchmark的比对。 再考虑真实的业务换算。可以用TPCC之类的做类比，但是我首先建议的是微基准评估，不掺杂任何上层应用的东西，直接对CPU、IO、FileSystem、Memory、Network进行benchmark Testing。在每个层面用到的工具都不一样，请参考我之前的一个文章《阿里云服务器ECS性能benchmark评估-系统级》。
今天用这环境试验了一下，本来是想为排队论收集一些分析数据的。但是由于一个人操作实在是过于繁琐，就先放一下了。改天找组内的人一起来做。
但是初试的结果确实可以拿到我想要的数据了。
线程数有了，到达率有了，响应时间也有了。后面就是要收集数据、分析模型了。大概统计了个简单的图如下所示，下面这个图明显就是有瓶颈的感觉了。等后面有空我再收拾环境中的各个问题。现在环境成型是首要的任务。
大家有想学习技术的人，开始一定要自己动手搭环境。搞清楚了逻辑之后，才着重关注深层次的问题。
并且一定要记笔记，不然自己做过什么都给忘掉了。
