高流量网站如何做出高性能？(前端、后端和存储服务器性能测试)

　　转至http://blog.oneapm.com/apm-tech/340.html做笔记，转载前请跟原作者联系！

　　前一段时间接触了一个教育集团的老总，集团本身是在教育实体化阶段也就是各种教科书盛行的时候起来的，最近 10 年互联网教育越来越火，老板也瞅准商机跳了进来。

　　可是公司的在线教育板块一直不温不火没有什么起色，Google Analytics、百度统计、CNZZ 数据专家等各种运营软件用了个遍还是老样子。

　　「你说为啥？」老总总是问身边的人。 

　　我尝试打开他公司的官网以及几个教育产品的网页，没有一个页面在 10s 内被打开。。。你说为啥？！ 

　　在时间如此精贵的当下，任何一个互联网公司如果不注重用户体验，一味的注重开发、上线、销售，其结局。。。不管你们想到没想到，我想到了。。。。

　　有一种声音总是在喊「我们要高性能网站！」于是各种服务器、各种 CDN、DNS 全上了之后却发现——花了不少效果不好。

　　那么，问题来了。。。。

一、什么叫高性能的网站？

　　现有两个网站性能架构设计方案：方案 A 和方案 B。方案 A 在小于100个并发用户访问时，每个请求的响应时间是1秒，当并发请求达到200的时候，请求的响应时间将骤增到10秒。方案 B 不管是100个还是200个并发访问，每个请求的响应时间都差不多是1.5秒。

　　哪个方案的性能好？

　　如果你的老板要求「我们要改善一下网站的性能」，你知道他指的是什么吗？

　　同类型的两个网站，X 网站服务器平均每个请求的处理时间是500毫秒，Y 网站服务器平均每个请求的处理时间是1000毫秒，为什么用户却反映 Y 网站的速度快呢？

　　网站性能是客观的指标，可以具体体现到响应时间、吞吐量等技术指标；同时也是主观的感受，而感受则是一种与具体参与者相关的微妙的东西，用户的感受和工程师的感受不同，不同的用户感受也不同。

　　说的再多最后都要上生产环境，所以，最直接、最真实 的就是把用户访问时的各项指标作为最终的判断依据。

　　打造一个高性能的网站，首先就是要了解性能，那么我们就需要一些指标来具体量化前端性能这个关键指标！

二、前端页面性能指标

　　1.Apdex指数

　　Apdex值和Apdex指数是国际通用标准，是对用户体验满意度的量化值。

　　基于「真实用户体验」，Apdex 定义了 3 个用户满意区间：「满意」、「可容忍」、「失望」，通过响应时间数值  来划分。T 值代表着用户满意的响应时间界限，国际上一般默认为 2s，也就是说满意区间就是 0~2s；页面响应时间超过 T 值用户就有些不满了，下一个区间「容忍」的界限值是 T 和 4T，即 4-8 秒之间为容忍区间；响应时间再长用户就开始考虑放弃了，最后一个区间「失望」的响应时间则大于 4T，即多于 8 秒。

　　采集一定时间内的 Apdex 值之后，经过计算可以得出 Apdex 指数，具体计算公式为:

Apdex 指数 = [ 满意数量 + （ 可容忍数量 / 2）] / 总样本数 

　　这样，用户访问页面的响应时间被量化为一个 0 到 1 之间的「Apdex 指数」，0 代表没有满意用户，1 则代表所有用户都满意。经过统计，基于页面性能的 Apdex 评分于用户的体验紧密关联, 为管理、研发、运维人员提供了一种通过应用性能量化值来评估用户满意度的方法。 

　　可行工具：New Relic、OneAPM Browser Insight

　　2.页面响应时间

　　说得再好，做的再多最后页面也是要上生产的，线上的页面用户最直接的感受，就是页面响应时间，也就是页面打开耗时。

　　很多前端性能工具对页面响应时间这个指数只是简单的在本地模拟下，也就是所谓的「拨测」；或者只是简单的通过 window.performance 接口把各个数据上传给使用者，根本无法展现用户的真实体验。

　　从技术的角度讲，一个页面的打开时间也是要划分为各个部分的，例如：首屏打开时间、白屏时间、dom文档打开时间、资源加载完成时间等；也要重视资源加载耗时详情，是哪些脚本或者 css 拖慢了页面的加载这些都要一目了然。只有这样，一旦页面响应时间过长，相关人员才能有针对性的去进行维护。 

　　可行工具：New Relic、OneAPM Browser Insight、AppDynamics、Ruxit

　　3.页面响应时间分布

　　想了想还是觉得有必要把这个指标从「页面响应时间」里面拿出来单独说。

　　顾名思义，页面响应时分布间就是一段时间内，用户访问页面的响应时间的分布图。其实大部分情况下，一个网站的维护只需照顾到绝大多数用户就可以了，没有必要为了满足各种极端情况而耗费各种资源，中国网络环境的复杂性相信大家都深有体会，所以这种统计就显得尤为必要， 

　　可行工具：OneAPM Browser Insight、AppDynamics、Ruxit

　　4.DNS、TCP耗时

　　浏览器和 WEB 服务器连接 TCP/IP 的消耗时间以及域名解析时间也是网站优化需要关注指标。

还是那句话————国内的网络环境极其复杂，所以导致经常有 DNS，CDN 不给力的情况，TCP 的连接也经常会不稳定。之前国内外有些工具可以通过模拟拨测的方式来计算 DNS 耗时等数据，但讲实在的，只是这种仿真数据的话 DNS 厂家才不会理你，所以，从用户真实体验的角度来收集这类耗时则显得尤为必要，而现在能做好这一点的工具确实不多，给大家推荐几个。  

　　可行工具：OneAPM Browser Insight、AppDynamics、Ruxit

　　PS：Python Agent 安装配置

三、后端性能测试方法

　　网站上线前以及上线后，相关的性能测试也是必须要有的。性能测试是一个总称，具体可细分为预期测试、负载测试、压力测试、稳定性测试。

　　1.预期测试

　　以系统设计初期规划的性能指标为目标，对系统不断施加压力，验证系统在资源可接受范围内，是否能达到性能预期。

　　2.负载测试

　　对系统不断地增加并发请求以增加系统压力，直到系统的某项或多项性能指标达到安全临界值，如某种资源已经呈饱和状态，这时继续对系统施加压力，系统的处理能力不但不能提高，反而会下降。

　　3.压力测试

　　超过安全负载的情况下，对系统继续施加压力，直到系统崩溃或不能再处理任何请求，以此获得系统最大压力承受能力。

　　4.稳定性测试

　　被测试系统在特定硬件、软件、网络环境条件下，给系统加载一定业务压力，使系统运行一段较长时间，以此检测系统是否稳定。在不同生产环境、不同时间点的请求压力是不均匀的，呈波浪特性，因此为了更好地模拟生产环境，稳定性测试也应不均匀地对系统施加压力。

　　性能测试是一个不断对系统增加访问压力，以获得系统性能指标、最大负载能力、最大压力承受能力的过程。所谓的增加访问压力，在系统测试环境中，就是不断增加测试程序的并发请求数，一般说来，性能测试遵循如下图所示的抛物线规律。

　　性能测试反应的是系统在实际生产环境中使用时，随着用户并发访问数量的增加，系统的处理能力。与性能曲线相对应的是用户访问的等待时间（系统响应时间）

　　在日常运行区间，可以获得最好的用户响应时间，随着并发用户数的增加，响应延迟越来越大，直到系统崩溃，用户失去响应。

　　而从 OneAPM 提供的 Browser Insight 的定位分析功能来看，跟这个图还是很相似的，只不过是 X 坐标轴是响应时间，Y 是访问次数。 

　　性能测试报告

　　测试结果报告应能够反映上述性能测试曲线的规律，阅读者可以得到系统性能是否满足设计目标和业务要求、系统最大负载能力、系统最大压力承受能力等重要信息，下表是一个简单示例：

当这些数据得到量化的之后，我们的目标就很明确了，那么最终我们为了打造一个高性能的网站，需要做哪些工作呢？接下来我们分析性能优化的一些策略！

四、性能优化策略

　　如果性能测试结果不能满足设计或业务需求，那么就需要寻找系统瓶颈，分而治之，逐步优化。

　　1.性能分析

　　大型网站结构复杂，用户从浏览器发出请求直到数据库完成操作事务，中间需要经过很多环节，如果测试或者用户报告网站响应缓慢，存在性能问题，必须对请求经历的各个环节进行分析，排查可能出现性能瓶颈的地方，定位问题!

　　排查一个网站的性能瓶颈和排查一个程序的性能瓶颈的手法基本相同：检查请求处理的各个环节的日志，分析哪个环节响应时间不合理、超过预期；然后检查监控数据，分析影响性能的主要因素是内存、磁盘、网络、还是 CPU？是代码问题还是架构设计不合理？或者系统资源确实不足？

　　2.性能优化

　　定位产生性能问题的具体原因后，就需要进行性能优化，根据网站分层架构，可分为 Web 前端性能优化、应用服务器性能优化、存储服务器性能优化 3 大类，每一类都非常重要，一款好的工具的重要性就不言而喻了。

　　目前，OneAPM 针对前端性能的优化产品，Browser Insight 可以让用户免费试用；同时包括针对应用服务器性能优化 Application Insight 产品以及针对存储服务器性能优化 Cloud Insight产品也都提供了免费版产品，希望能够帮助用户不断优化，做出真正意义上的高性能高流量网站！！！

 

 

存储服务器性能测试

redis压力测试

　　转载至http://www.redis.cn/topics/benchmarks.html，转载前请跟原作者联系。

1.Redis有多快?

　　Redis 自带了一个叫 redis-benchmark 的工具来模拟 N 个客户端同时发出 M 个请求。 （类似于 Apache ab 程序）。你可以使用 redis-benchmark -h 来查看基准参数。

 

以下参数被支持：

Usage: redis-benchmark [-h <host>] [-p <port>] [-c <clients>] [-n <requests]> [-k <boolean>]

 -h <hostname>      Server hostname (default 127.0.0.1)
 -p <port>          Server port (default 6379)
 -s <socket>        Server socket (overrides host and port)
 -a <password>      Password for Redis Auth
 -c <clients>       Number of parallel connections (default 50)
 -n <requests>      Total number of requests (default 100000)
 -d <size>          Data size of SET/GET value in bytes (default 2)
 -dbnum <db>        SELECT the specified db number (default 0)
 -k <boolean>       1=keep alive 0=reconnect (default 1)
 -r <keyspacelen>   Use random keys for SET/GET/INCR, random values for SADD
  Using this option the benchmark will expand the string __rand_int__
  inside an argument with a 12 digits number in the specified range
  from 0 to keyspacelen-1. The substitution changes every time a command
  is executed. Default tests use this to hit random keys in the
  specified range.
 -P <numreq>        Pipeline <numreq> requests. Default 1 (no pipeline).
 -q                 Quiet. Just show query/sec values
 --csv              Output in CSV format
 -l                 Loop. Run the tests forever
 -t <tests>         Only run the comma separated list of tests. The test
                    names are the same as the ones produced as output.
 -I                 Idle mode. Just open N idle connections and wait.

　　你需要在基准测试之前启动一个 Redis 实例。

 

　　一般这样启动测试：

redis-benchmark -q -n 100000

　　这个工具使用起来非常方便，同时你可以使用自己的基准测试工具， 不过开始基准测试时候，我们需要注意一些细节。 

 

　　只运行一些测试用例的子集

　　你不必每次都运行 redis-benchmark 默认的所有测试。使用 -t 参数可以选择你需要运行的测试用例，比如下面的范例：

 

$ redis-benchmark -t set,lpush -n 100000 -q
SET: 74239.05 requests per second
LPUSH: 79239.30 requests per second

　　在上面的测试中，我们只运行了 SET 和 LPUSH 命令， 并且运行在安静模式中（使用 -q 参数）。 也可以直接指定命令来直接运行，比如下面的范例：

$ redis-benchmark -n 100000 -q script load "redis.call('set','foo','bar')"
script load redis.call('set','foo','bar'): 69881.20 requests per second

　　选择测试键的范围大小 默认情况下面，基准测试使用单一的 key。在一个基于内存的数据库里， 单一 key 测试和真实情况下面不会有巨大变化。当然，使用一个大的 key 范围空间， 可以模拟现实情况下面的缓存不命中情况。

 

　　这时候我们可以使用 -r 命令。比如，假设我们想设置 10 万随机 key 连续 SET 100 万次，我们可以使用下列的命令：

$ redis-cli flushall
OK

$ redis-benchmark -t set -r 100000 -n 1000000
====== SET ======
  1000000 requests completed in 13.86 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

99.76% `<=` 1 milliseconds
99.98% `<=` 2 milliseconds
100.00% `<=` 3 milliseconds
100.00% `<=` 3 milliseconds
72144.87 requests per second

$ redis-cli dbsize
(integer) 99993

 

　　使用 pipelining

　　默认情况下，每个客户端都是在一个请求完成之后才发送下一个请求 （benchmark 会模拟 50 个客户端除非使用 -c 指定特别的数量）， 这意味着服务器几乎是按顺序读取每个客户端的命令。Also RTT is payed as well.

　　真实世界会更复杂，Redis 支持 /topics/pipelining，使得可以一次性执行多条命令成为可能。 Redis pipelining 可以提高服务器的 TPS。 下面这个案例是在 Macbook air 11” 上使用 pipelining 组织 16 条命令的测试范例：

　　$ redis-benchmark -n 1000000 -t set,get -P 16 -q

　　SET: 403063.28 requests per second

　　GET: 508388.41 requests per second

　　记得在多条命令需要处理时候使用 pipelining。

　　陷阱和错误的认识

　　第一点是显而易见的：基准测试的黄金准则是使用相同的标准。 用相同的任务量测试不同版本的 Redis，或者用相同的参数测试测试不同版本 Redis。 如果把 Redis 和其他工具测试，那就需要小心功能细节差异。

 

1. 　　Redis 是一个服务器：所有的命令都包含网络或 IPC 消耗。这意味着和它和 SQLite， Berkeley DB， Tokyo/Kyoto Cabinet 等比较起来无意义， 因为大部分的消耗都在网络协议上面。
2. 　　Redis 的大部分常用命令都有确认返回。有些数据存储系统则没有（比如 MongoDB 的写操作没有返回确认）。把 Redis 和其他单向调用命令存储系统比较意义不大。
3. 　　简单的循环操作 Redis 其实不是对 Redis 进行基准测试，而是测试你的网络（或者 IPC）延迟。想要真正测试 Redis，需要使用多个连接（比如 redis-benchmark)， 或者使用 pipelining 来聚合多个命令，另外还可以采用多线程或多进程。
4. 　　Redis 是一个内存数据库，同时提供一些可选的持久化功能。 如果你想和一个持久化服务器（MySQL, PostgreSQL 等等） 对比的话， 那你需要考虑启用 AOF 和适当的 fsync 策略。
5. 　　Redis 是单线程服务。它并没有设计为多 CPU 进行优化。如果想要从多核获取好处， 那就考虑启用多个实例吧。将单实例 Redis 和多线程数据库对比是不公平的。

 

　　一个普遍的误解是 redis-benchmark 特意让基准测试看起来更好， 所表现出来的数据像是人造的，而不是真实产品下面的。Redis-benchmark 程序可以简单快捷的对给定硬件条件下面的机器计算出性能参数。 但是，通常情况下面这并不是 Redis 服务器可以达到的最大吞吐量。 事实上，使用 pipelining 和更快的客户端（hiredis）可以达到更大的吞吐量。 redis-benchmark 默认情况下面仅仅使用并发来提高吞吐量（创建多条连接）。 它并没有使用 pipelining 或者其他并行技术（仅仅多条连接，而不是多线程）。

　　如果想使用 pipelining 模式来进行基准测试（了达到更高吞吐量），可以使用 -P 参数。这种方案的确可以提高性能，有很多使用 Redis 的应用在生产环境中这样做。

　　最后，基准测试需要使用相同的操作和数据来对比，如果这些不一样， 那么基准测试是无意义的。

　　比如，Redis 和 memcached 可以在单线程模式下面对比 GET/SET 操作。 两者都是内存数据库，协议也基本相同，甚至把多个请求合并为一条请求的方式也类似 （pipelining）。在使用相同数量的连接后，这个对比是很有意义的。

　　下面这个很不错例子是在 Redis（antirez）和 memcached（dormando）测试的。

　　antirez 1 - On Redis, Memcached, Speed, Benchmarks and The Toilet

　　dormando - Redis VS Memcached (slightly better bench)

　　antirez 2 - An update on the Memcached/Redis benchmark

　　你可以发现相同条件下面最终结果是两者差别不大。请注意最终测试时候， 两者都经过了充分优化。

　　最后，当特别高性能的服务器在基准测试时候（比如 Redis、memcached 这类）， 很难让服务器性能充分发挥，通常情况下，客户端回事瓶颈限制而不是服务器端。 在这种情况下面，客户端（比如 benchmark 程序自身）需要优化，或者使用多实例， 从而能达到最大的吞吐量。

　　影响 Redis 性能的因素

　　有几个因素直接决定 Redis 的性能。它们能够改变基准测试的结果， 所以我们必须注意到它们。一般情况下，Redis 默认参数已经可以提供足够的性能， 不需要调优。

 

1. 　　网络带宽和延迟通常是最大短板。建议在基准测试之前使用 ping 来检查服务端到客户端的延迟。根据带宽，可以计算出最大吞吐量。 比如将 4 KB 的字符串塞入 Redis，吞吐量是 100000 q/s，那么实际需要 3.2 Gbits/s 的带宽，所以需要 10 GBits/s 网络连接， 1 Gbits/s 是不够的。 在很多线上服务中，Redis 吞吐会先被网络带宽限制住，而不是 CPU。 为了达到高吞吐量突破 TCP/IP 限制，最后采用 10 Gbits/s 的网卡， 或者多个 1 Gbits/s 网卡。
2. 　　CPU 是另外一个重要的影响因素，由于是单线程模型，Redis 更喜欢大缓存快速 CPU， 而不是多核。这种场景下面，比较推荐 Intel CPU。AMD CPU 可能只有 Intel CPU 的一半性能（通过对 Nehalem EP/Westmere EP/Sandy 平台的对比）。 当其他条件相当时候，CPU 就成了 redis-benchmark 的限制因素。
3. 　　在小对象存取时候，内存速度和带宽看上去不是很重要，但是对大对象（> 10 KB）， 它就变得重要起来。不过通常情况下面，倒不至于为了优化 Redis 而购买更高性能的内存模块。
4. 　　Redis 在 VM 上会变慢。虚拟化对普通操作会有额外的消耗，Redis 对系统调用和网络终端不会有太多的 overhead。建议把 Redis 运行在物理机器上， 特别是当你很在意延迟时候。在最先进的虚拟化设备（VMWare）上面，redis-benchmark 的测试结果比物理机器上慢了一倍，很多 CPU 时间被消费在系统调用和中断上面。
5. 　　如果服务器和客户端都运行在同一个机器上面，那么 TCP/IP loopback 和 unix domain sockets 都可以使用。对 Linux 来说，使用 unix socket 可以比 TCP/IP loopback 快 50%。 默认 redis-benchmark 是使用 TCP/IP loopback。 当大量使用 pipelining 时候，unix domain sockets 的优势就不那么明显了。
6. 　　当大量使用 pipelining 时候，unix domain sockets 的优势就不那么明显了。当使用网络连接时，并且以太网网数据包在 1500 bytes 以下时， 将多条命令包装成 pipelining 可以大大提高效率。事实上，处理 10 bytes，100 bytes， 1000 bytes 的请求时候，吞吐量是差不多的，详细可以见下图。

　　在多核 CPU 服务器上面，Redis 的性能还依赖 NUMA 配置和 处理器绑定位置。 最明显的影响是 redis-benchmark 会随机使用 CPU 内核。为了获得精准的结果， 需要使用固定处理器工具（在 Linux 上可以使用 taskset 或 numactl）。 最有效的办法是将客户端和服务端分离到两个不同的 CPU 来高校使用三级缓存。 这里有一些使用 4 KB 数据 SET 的基准测试，针对三种 CPU（AMD Istanbul, Intel Nehalem EX， 和 Intel Westmere）使用不同的配置。请注意， 这不是针对 CPU 的测试。

　　在高配置下面，客户端的连接数也是一个重要的因素。得益于 epoll/kqueue， Redis 的事件循环具有相当可扩展性。Redis 已经在超过 60000 连接下面基准测试过， 仍然可以维持 50000 q/s。一条经验法则是，30000 的连接数只有 100 连接的一半吞吐量。 下面有一个关于连接数和吞吐量的测试。

　　在高配置下面，可以通过调优 NIC 来获得更高性能。最高性能在绑定 Rx/Tx 队列和 CPU 内核下面才能达到，还需要开启 RPS（网卡中断负载均衡）。更多信息可以在 thread 。Jumbo frames 还可以在大对象使用时候获得更高性能。 

　　在不同平台下面，Redis 可以被编译成不同的内存分配方式（libc malloc, jemalloc, tcmalloc），他们在不同速度、连续和非连续片段下会有不一样的表现。 如果你不是自己编译的 Redis，可以使用 INFO 命令来检查内存分配方式。 请注意，大部分基准测试不会长时间运行来感知不同分配模式下面的差异， 只能通过生产环境下面的Redis实例来查看。

　　其他需要注意的点

　　任何基准测试的一个重要目标是获得可重现的结果，这样才能将此和其他测试进行对比。 

 

1. 　　一个好的实践是尽可能在隔离的硬件上面测试。如果没法实现，那就需要检测 benchmark 没有受其他服务器活动影响。 
2. 　　有些配置（桌面环境和笔记本，有些服务器也会）会使用可变的 CPU 分配策略。 这种策略可以在 OS 层面配置。有些 CPU 型号相对其他能更好的调整 CPU 负载。 为了达到可重现的测试结果，最好在做基准测试时候设定 CPU 到最高使用限制。 
3. 　　一个重要因素是配置尽可能大内存，千万不要使用 SWAP。注意 32 位和 64 位 Redis 有不同的内存限制。
4. 　　如果你计划在基准测试时候使用 RDB 或 AOF，请注意不要让系统同时有其他 I/O 操作。 避免将 RDB 或 AOF 文件放到 NAS 或 NFS 共享或其他依赖网络的存储设备上面（比如 Amazon EC2 上 的 EBS）。 将 Redis 日志级别设置到 warning 或者 notice。
5. 　　避免将日志放到远程文件系统。 避免使用检测工具，它们会影响基准测试结果。使用 INFO 来查看服务器状态没问题， 但是使用 MONITOR 将大大影响测试准确度。

 

2.不同云主机和物理机器上的基准测试结果

 

1. 　　这些测试模拟了 50 客户端和 200w 请求。 
2. 　　使用了 Redis 2.6.14。 
3. 　　使用了 loopback 网卡。
4. 　　key 的范围是 100 w。 
5. 　　同时测试了 有 pipelining 和没有的情况（16 条命令使用 pipelining）。 

 

　　Intel(R) Xeon(R) CPU E5520 @ 2.27GHz (with pipelining)

 

$ ./redis-benchmark -r 1000000 -n 2000000 -t get,set,lpush,lpop -P 16 -q
SET: 552028.75 requests per second
GET: 707463.75 requests per second
LPUSH: 767459.75 requests per second
LPOP: 770119.38 requests per second

 

　　Intel(R) Xeon(R) CPU E5520 @ 2.27GHz (without pipelining)

 

$ ./redis-benchmark -r 1000000 -n 2000000 -t get,set,lpush,lpop -q
SET: 122556.53 requests per second
GET: 123601.76 requests per second
LPUSH: 136752.14 requests per second
LPOP: 132424.03 requests per second

 

　　Linode 2048 instance (with pipelining)

$ ./redis-benchmark -r 1000000 -n 2000000 -t get,set,lpush,lpop -q -P 16
SET: 195503.42 requests per second
GET: 250187.64 requests per second
LPUSH: 230547.55 requests per second
LPOP: 250815.16 requests per second

　　Linode 2048 instance (without pipelining)

$ ./redis-benchmark -r 1000000 -n 2000000 -t get,set,lpush,lpop -q
SET: 35001.75 requests per second
GET: 37481.26 requests per second
LPUSH: 36968.58 requests per second
LPOP: 35186.49 requests per second

 

mysql压力测试

　　转载至http://xstarcd.github.io/wiki/MySQL/mysqlslap.html，转载前请跟原作者联系。

　　mysql自带就有一个叫mysqlslap的压力测试工具，还是模拟的不错的。下面举例说说。mysqlslap是从5.1.4版开始的一个MySQL官方提供的压力测试工具。通过模拟多个并发客户端访问MySQL来执行压力测试，同时详细的提供了“高负荷攻击MySQL”的数据性能报告。并且能很好的对比多个存储引擎在相同环境下的并发压力性能差别。通过mysqlslap –help可以获得可用的选项，这里列一些主要的参数，更详细的说明参考官方手册。如果是系统自带或者使用rpm包安装的mysql，安装了MySQL-client端的包就有mysqlslap这个工具。

　　下图是运行mysqlslap -a -c 500 -i 10 -uroot -p123456测试时mysql的连接进程数:(略，mysql中运行show proccesslist;可以看到有大量连接)

1.语法参数

　　使用语法如下： 

 

mysqlslap [options]

 

　　常用参数 [options] 详细说明：  

 

--auto-generate-sql, -a 自动生成测试表和数据，表示用mysqlslap工具自己生成的SQL脚本来测试并发压力。
--auto-generate-sql-load-type=type 测试语句的类型。代表要测试的环境是读操作还是写操作还是两者混合的。取值包括：read，key，write，update和mixed(默认)。
--auto-generate-sql-add-auto-increment 代表对生成的表自动添加auto_increment列，从5.1.18版本开始支持。
--number-char-cols=N, -x N 自动生成的测试表中包含多少个字符类型的列，默认1
--number-int-cols=N, -y N 自动生成的测试表中包含多少个数字类型的列，默认1
--number-of-queries=N 总的测试查询次数(并发客户数×每客户查询次数)
--query=name,-q 使用自定义脚本执行测试，例如可以调用自定义的一个存储过程或者sql语句来执行测试。
--create-schema 代表自定义的测试库名称，测试的schema，MySQL中schema也就是database。
--commint=N 多少条DML后提交一次。
--compress, -C 如果服务器和客户端支持都压缩，则压缩信息传递。
--concurrency=N, -c N 表示并发量，也就是模拟多少个客户端同时执行select。可指定多个值，以逗号或者--delimiter参数指定的值做为分隔符。例如：--concurrency=100,200,500。
--engine=engine_name, -e engine_name 代表要测试的引擎，可以有多个，用分隔符隔开。例如：--engines=myisam,innodb。
--iterations=N, -i N 测试执行的迭代次数，代表要在不同并发环境下，各自运行测试多少次。
--only-print 只打印测试语句而不实际执行。
--detach=N 执行N条语句后断开重连。
--debug-info, -T 打印内存和CPU的相关信息。

　　测试的过程需要生成测试表，插入测试数据，这个mysqlslap可以自动生成，默认生成一个mysqlslap的schema，如果已经存在则先删除。可以用--only-print来打印实际的测试过程，整个测试完成后不会在数据库中留下痕迹。  

 

2.测试实例

　　各种测试参数实例（-p后面跟的是mysql的root密码）：

 

# 单线程测试。测试做了什么。
mysqlslap -a -uroot -p123456
 
# 多线程测试。使用–concurrency来模拟并发连接。
mysqlslap -a -c 100 -uroot -p123456
 
# 迭代测试。用于需要多次执行测试得到平均值。
mysqlslap -a -i 10 -uroot -p123456
 
mysqlslap ---auto-generate-sql-add-autoincrement -a -uroot -p123456
mysqlslap -a --auto-generate-sql-load-type=read -uroot -p123456
mysqlslap -a --auto-generate-secondary-indexes=3 -uroot -p123456
mysqlslap -a --auto-generate-sql-write-number=1000 -uroot -p123456
mysqlslap --create-schema world -q "select count(*) from City" -uroot -p123456
mysqlslap -a -e innodb -uroot -p123456
mysqlslap -a --number-of-queries=10 -uroot -p123456
 
# 测试同时不同的存储引擎的性能进行对比：
mysqlslap -a --concurrency=50,100 --number-of-queries 1000 --iterations=5 --engine=myisam,innodb --debug-info -uroot -p123456
 
# 执行一次测试，分别50和100个并发，执行1000次总查询：
mysqlslap -a --concurrency=50,100 --number-of-queries 1000 --debug-info -uroot -p123456
 
# 50和100个并发分别得到一次测试结果(Benchmark)，并发数越多，执行完所有查询的时间越长。为了准确起见，可以多迭代测试几次:
mysqlslap -a --concurrency=50,100 --number-of-queries 1000 --iterations=5 --debug-info -uroot -p123456