MySQL基准测试(一)--原因，策略，思路

标签：配置   网络   需要   cache   添加   应用层   res   操作系统。   时间段   

MySQL基准测试(一)--原因，策略，思路

运用benchmark的原因

• 验证一些你认为的问题，通过基准测试和模拟数据来验证。
• 解决生产系统的一些异常
• 测试系统的当前的运行情况，通过历史的基准测试结果分析。
• 模拟更高的负载，发现一些“天花板”等瓶颈问题
• 规划的未来业务增长。通过基准测试评估，来规划硬件，网络，其他资源。保证生产环境的稳定运行。
• 测试应用在高并发情况下(高峰值)的性能表现。(这里不仅对数据库，对网络，存储，tomcat等web应用同样适用)
• 测试不同的硬件，操作系统。
• 测试采购的设备的配置参数是否正确。

运用benchmark的策略

• 测试整个应用环境：包括Web服务器，应用代码，网路，数据库等。不仅仅是数据库，而应该是对于整个应用的性能，因为用户关注的是页面的响应时间，对于整个网站的感官速度，而不是数据库本身。甚至用户都不懂数据库为何物
• MySQL数据库并不是应用的唯一瓶颈:当数据库的load和慢查询以及参数各个方面都ok的时候，我们应该去梳理整个架构。从应用层开始从上倒下的梳理，比只看数据库的单方面来的性能优化的效益更高。

针对数据库

• 比较不同的schema或查询的性能。(可以在不同的硬件环境，不同的操作系统，不同的数据库版本下测试，不同的mysql参数配置）
• 针对某个应用问题反映的性能问题，做基准测试
• 针对某个场景(高峰)，做一个短期的基准测试，周期性的(每隔一天，每隔三天，或者每隔一周)不同时间段的基准测试。来分析问题。

运用benchmark的需分析的指标

• 吞吐量
  吞吐量指的是单位时间内的事务处理数。常用的单位指标每秒事务数(TPS),每分钟事务数(TPM)。
• 响应时间
  测试单位任务所需的时间。例如一个具体的应用，测试某一个页面的响应时间。并且通过一个百分比响应时间(percentile response time)来代替。例如:访问某一个具体应用的某一个页面的95%的时间都是20ms，那么这个页面的响应时间可以说是在20ms内响应完成。
• 并发性
  这个并发性是一个具有迷惑性的指标，例如多少用户在同一个时间访问一个web站点，并不代表具有多少并发请求，因为HTTP是无状态的，很多人访问的只是web站点的静态页面。并不等于web服务器的请求。而且，web服务器的请求也不等同于数据库的并发请求。
  因此，到数据库并发请求的时候，并发请求已经少之又少了。一个代码设计良好的应用程序，应该是一个web站点同一时间有10万用户访问，却只可能有30～50个数据库的并发请求。
• 可扩展性
  当应用系统的遇到业务压力的时候，系统有可扩展性是必须的。例如:tomcat等此类web应用能不能扩展，具有负载均衡的能力。数据库是否有可扩展性，分担读请求的负载能力。因为当吞吐量和性能不能纵向扩展的话。就必须从横向扩展，增加吞吐量。提供整个架构的性能。

而何时需要扩展？何时遇到瓶颈？那么收集生产环境上的状态指标就非常有必要，包括web应用和数据库等状态指标。来分析遇到了哪些瓶颈？

运用benchmark的思路

收集 -->分析 -->决策 -->优化

• 收集 收集尽可能多的生产环境的状态数据。基于客观事实做出来的优化，总比凭着经验更为靠谱。有时候经验做出来的决策其实会更危险。
• 分析 基准测试收集来的数据，不管使用何种工具，都需要人的眼睛基于客观的数据做出分析，需要做哪些方面的优化。
• 决策 分析出来的结果，例如：数据库的参数需要调整，数据库的SQL或者索引需要优化，数据库的schema需要优化，需要加一个cache层。以及硬件，网络，存储需要优化等等。在例如应用层面或者代码。这些需要沟通的，以最小的代价获得最高性能的提升。需要团队大家一起沟通而不是单方面的决定。
• 优化 以10%的成本来获得40%的性能优化。这个有取舍。例如:本来需要修改表结构亦或者添加索引，得到一个数据库的性能增进。又发现数据库的参数未优化。通过调整一些参数来提高数据库的性能。后面发现这是一个中小型的网站，有一定的维护停机时间可行性。通过分析，决定修改参数配置重启数据库，只有10s左右的停机时间，获得更好的数据库性能。而不需要修改现有的表结构。这是一个平衡的调整。

MySQL基准测试(一)--原因，策略，思路

标签：配置   网络   需要   cache   添加   应用层   res   操作系统。   时间段   

原文地址：https://www.cnblogs.com/zhangshengdong/p/9190469.html