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)、多机配合(集群) 的直观掌握

 

具体步骤 后续添加

 

 

1 收藏


直接登录