今日大事记之mysql cache和bzm - Concurrency Thread Group
背景
昨天用fiddler抓包转为jmeter脚本后，今天配置了csv data进行压测。
第一滴血
参考
Let’s look at the following scenario:
- 100 threads
- 30 minutes Ramp Up Time
- 10 Ramp-Up Steps
- 30 minutes holding the target rate
This means that:
- Every 3 minutes 10 users will be added until we reach 100 users. ( 30 minutes divided by 10 steps equals 3 minutes per step. 100 users divided by 10 steps equals 10 users per step. Totalling - 10 users every 3 minutes).
- After reaching 100 threads all of them will continue running and hitting the server together for 30 minutes
The Concurrency Thread Group also shows us the test in a real-time preview graph.
Increase imagejmeter concurrency thread group preview paragraph
存疑的两点
1、每个request的samples？
2、执行脚本后，多久结束？
第二滴血
压测过程中开了慢查询日志后，发现了慢查询语句，想用explain和profiling分析语句，结果发现多次执行相同的sql，第一次执行的时间与后面执行时间相差巨大。
query cache
首当其冲想到了query cache, 随后用上了各种技巧，诸如：
show variables like '%cache%'
set global query_cache_type=0;
set global query_cache_size=0;
flush query cache;
reset query cache;
问题依旧存在，随后便大量查阅资料，看到dev-mysql的官网介绍说，所用版本的query cache相关系统变量已被弃用。
存疑
既然query cache 都禁掉了，为何还会有cache到？
说到底还是不了解mysql的cache缓存原理，于是各种google，找到了宝：
https://stackoverflow.com/questions/16043943/how-to-disable-mysql-query-caching#
可以算是失败的一天
一来没彻底搞懂jmeter bzm - Concurrency Thread Group
二来没搞懂mysql cache
