压力测试

在运维工作中，压力测试是一项很重要的工作。比如在一个网站上线之前，能承受多大访问量、在大访问量情况下性能怎样，这些数据指标好坏将会直接影响用户体验。但是，在压力测试中存在一个共性，那就是压力测试的结果与实际负载结果不会完全相同，就算压力测试工作做的再好，也不能保证100%和线上性能指标相同。面对这些问题，我们只能尽量去想方设法去模拟。所以，压力测试非常有必要，有了这些数据，我们就能对自己做维护的平台做到心中有数。

我们通常说的网站流量(traffic)就是指网站的访问量，是用来描述访问一个网站的用户数量以及用户所浏览的网页数量等指标，常用的统计指标包括网站的独立用户数量、总用户数量(含重复访问者)、网页浏览数量、每个用户的页面浏览数量、用户在网站的平均停留时间等。

并发模式与RPS模式压测各有各自的使用场景，并发模式更加适用于对于系统定性的分析，比如帮助定位性能瓶颈，单接口的性能基线沉淀（对比历史性能优化or劣化）；而RPS模式在对系统做定量的分析有杰出表现，比如容量规划、全链路性能基线沉淀，当然也可以帮助定位性能瓶颈。并发模式的难点在于RT的准确性拟真，RPS模式的难点在于模型的准确性评估和预测，从实现难度上来说，前者相对于后者来说难度更大一些、掌控度更低一些。

并发指标

• 并发用户、并发、VU：一般用来表示虚拟用户（Virutal User，简称VU），对应到Jmeter的线程组线程，对应到Loadrunner的并发Concurrency，在本文都是一个意思。

• 每秒发送请求数、RPS：指客户端每秒发出的请求数，有些地方也叫做QPS，本文不单独讨论“事务”所以可以近似对应到Loadrunner的TPS（Transaction Per Second,每秒事务数），本文统一叫做RPS。

• 响应时间、RT：对，没错，这个就是你理解的那个意思，从发起请求到完全接收到应答的时间消耗。

根据“Little定律”，在平衡状态下，我们可以等价认为并发、RPS和RT之间的关系可以概括为

并发数= RPS *响应时间

数据库压力测试

sudo aptitude install sysbench
echo "create database sbtest; grant all on sbtest.* to 'sbtest'@'localhost';" | mysql
sysbench --test=oltp --num-threads=10 prepare
sysbench --test=oltp --num-threads=10 run

sysbench --test=oltp --num-threads=16 --max-requests=100000 --mysql-socket=/var/lib/mysql/mysql.sock --mysql-user=root --db-driver=mysql --oltp-test-mode=complex run

随着NoSql数据存储方式的使用率增加，以及多存储方式混合解决方案日趋流行，开发团队在需要存储数据时有了多种选择。虽然这能带来很多益处，但是在不稳定的网络环境下产品行为有可能出现微妙的(以及不那么微妙的)问题，而这些问题有时即便是产品开发人员自己也难以理解。当任何人试图了解不同数据库和队列技术在不同场景下如何反应时，事实上都会把Jepsen及其博客作为参考。关键一点，使用这种在事务中包含客户端的方法来测试，给许多构建微服务的团队揭示了可能的错误模式。