mysql存储服务器S:i5,8G,ssd; centos 7 x64; 安装图形化监控工具(监控工具自身也要消耗资源)
jetty应用服务器A:i5,8G,ssd; centos 7 x64; 安装图形化监控工具(监控工具自身也要消耗资源)
局域网内测试机T:i5,8G,ssd
如何获得S和A的极限性能参数，以及S和A配合后的极限性能参数
确保局域网带宽不是瓶颈.
S服务测试方法:
在T上编写python脚本,确保python脚本的执行不是瓶颈. 或用mysql测试工具。
1、只打开mysql连接，不关闭mysql连接，观测S各项测参数(cpu、RAM、网络流量出入、磁盘IO)趋势图。 增加并行数目（注意T上直观的看到的是并发数目，并发数目通常是并行数目的若干倍。T的能力决定了可打达到的最大并行数目），经历的各个阶段预想：正常打开连接，打开连接所消耗时间明显变长(由此可确定mysql维持一个连接所消耗的主要资源是什么)，无法打开连接，S死机。
2a、打开mysql连接，select 一个复杂常量表达式，关闭连接。 增加并行数目，经历的各个阶段预想：正常，CPU消耗猛。
2b、将复杂表达式改为执行指定时长的存储过程调用。 增加并行数目，经历的各个阶段预想：正常，CPU消耗猛，S死机。 观察S经历的资源占用变化。
3、构造一个表，只插入。 增加并发数目， 观看S资源占用变化。 由此放大 一条insert 语句所经历的各个阶段的消耗
4、一个表，大小超出8GB，只插入。 观察此时S。
5、一个表，先插入，再查询。 增加并发数，观察。 这是一般电商系统单服务器承受的压力 （放大后得到什么现象？）
6、构造内存表，重新模拟3、4(表大小改为内存一半)、5，观察现象。 得出在无磁盘瓶颈情况下，cpu、ram的极限。
7、内存表，select a from t1 where 非索引字段='xx'， 使用不同大小的的t1表，观测。 观测非索引情况下条件
8、将7的字段改为索引字段，且索引文件放在内存中。观测。
9、内存表，group by 非索引字段，观测。
10、将9改为索引字段，索引文件在内存中。观测。
11、触发器，调高，观测.
12、用户表join订单表join商品表,观测.
13、磁盘表, select id ...where ... 和 select * ...where ..., (注意加变化的条件以抵抗mysql查询缓存) 对比观测. 放大的是同一行记录之间在磁盘上的存储规律.
...待续
jetty部分 spring mvc+freemarker
jetty日志文件配置到内存分区下，设定为32MB后丢弃。防止磁盘先作为瓶颈.
1、 请求控制器中的一个空方法，调高并行，观察A。 此时放大的应该是spring mvc自身、网络带宽、jvm自身的消耗。
2、请求控制器中的一个死循环方法，调高并行，观察A。观察死机时的状况。
3、控制器中存在一个sleep10秒，调高并行，观察A。
4、方法中加入new ArrayList(100)，调高并行，观察A.
5、 方法中构造一个引用环状依赖，确保两个对象彼此都不会被垃圾回收线程回收，确保每次泄漏1MB内存，调高并发，观察A.
6、 方法中直接做2/0操作, 调高并发，观察A。 如果能放大，看到的应该是异常在方法调用链条上传播的消耗。
7、将6改为(int)1.0
8、freemarker循环一个1MB的数组, 调高并发, 观察.
mysql jetty结合
1、内存表user大小2GB，执行登录（查询user，md5, 记录session，返回首页内容），调高并行. 观测S、A，谁先死机。若不死机，增加更多个T，每个T调整到接近T死机的并行数目.
2、 1中 若A先死机，改为A1 A2 S ，调高并行直到死机.
3、 1中 若S先死机，则改为A S1 S2, 调高并行直到死机.
4、内存表, 显示一页商品， 下单， 更改订单状态。 调高并发，观测. 这是放大电商下单.
5、将4中商品、订单表大小都改为1/4内存大小
6、操作日志，随机显示某一页。调高并发.
...待续
以上实验 目的是关于 磁盘IO、 计算机（cpu、ram）、多机配合（集群） 的直观掌握
具体步骤 后续添加
