九月廿三 壬寅年 虎 庚戌月 甲辰日 全国在降温之际

不管如何，今天总算是执行起来了脚本。在配置了性能工具之Jmeter 后置监听器可视化数据逻辑的界面中，看到下图：

显然 TPS 在这个接口中能达到 1500 以上，这对第一次执行来说，是个非常不错的结果了。从资源上看：

s8、s9的带宽用起来了，经过几位学员的监控，也看到了定向监控中的其他数据，如下：

显然软中断较为集中仍然是阿里云服务器在TPS高的时候不可忽略的痛点。这一点也希望购买了云服务器的企业能够关注，仅此一点就可以产生大量的计算资源的浪费。
在分析了这个接口的数据量之后，觉得没什么可以减少的网络流量，接口数据很小。在解决不了网络流量大小的前提下，先把集中的服务分散，以便使用到不同的云服务器。在调整了服务到不同服务器之后，得到如下结果：

上图中出错的那个点就是调整服务的时候，从上图可以看出调整前后 TPS 是有变化的，从1700到2100左右，增加了400左右。从这个结果上来看，也算是有了 TPS 的上升，算是个不错的调优结果。
对于si 的集中仍然存在的问题，只能提个工单给阿里云了。

虽然si集中的问题暂时不能解决，但我们也不是没活可见，下面是数据库监控的一些图。

从图上看，像 innodb_buffer_pool_size、query_cache_size、open_table 之类的相关参数还是要调的，暂时还不知道调了之后的效果。等他们做了之后，再看吧。
对于这样的硬件环境（见《7DGroup性能实施项目方案》），一个独立的接口跑到2000多，倒也算是不错了。虽然这个接口比较简单。

这个执行结果，我觉得还是不错的。在我们学员的通力配合之下，大家也终于进入了执行环节，并且也见到了一些具体分析案例。

我在让大家写分析的过程，希望他们写的东西，也能在后面分享出来，这就取决于文档功底了。
我觉得这个具体的案例倒不是最重要的，重要的是大家能不能跟着分析逻辑走下去。这才是大家要锻炼的能力，以免遇到下一个问题仍然手忙脚乱。