吞吐量

MySQL 的QPS吞吐量或者说TPS与很多因素有关，例如CPU、内存以及硬盘等。 《高性能MySQL》第三版 1.5小节对各个版本的MySQL进行了测试，其结果如下。 测试机器 测试机器Cisco UCSC250 内存384GB 存储引擎是InnoDB 测试的数据集2.5GB MySQL的buffer pool设置为4GB 从上面的数据看，最大QPS 不到8000。 对于插入和更新操作的吞吐量，可以推测大约就是这个数字附近。 网上搜索其他测试数据，QPS大约是7000左右。 参考 《高性能MySQL》第3版 https://www.cnblogs.com/springsource/p/5961048.html http://yansu.org/2014/04/16/insert-large-number-of-data-in-mysql.html 来源： CSDN 作者： kingmax54212008 链接： https://blog.csdn.net/kingmax54212008/article/details/104104601

一、QPS/TPS QPS：Queries Per Second的缩写，意思是“每秒查询率”，是一台服务器每秒能够相应的查询次数，是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。 TPS： Transactions Per Second的缩写，也就是事务数/秒（每秒处理的事务数）。它是软件测试结果的测量单位。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数。 TPS即每秒处理事务数，包括了 用户请求服务器 服务器自己的内部处理 服务器返回给用户 这三个过程，每秒能够完成N个这三个过程，TPS也就是N； QPS基本类似于TPS （有时候也会把两者当成一个），但是不同的是，对于一个页面的一次访问，形成一个TPS；但一次页面请求，可能产生多次对服务器的请求，服务器对这些请求，就可计入“QPS”之中。 例如：访问一个页面会请求服务器3次，一次放，产生一个“T”，产生3个“Q” 二、系统吞吐量 一个系统的吞度量（承压能力）与request对CPU的消耗、外部接口、IO等等紧密关联。单个reqeust 对CPU消耗越高，外部系统接口、IO影响速度越慢，系统吞吐能力越低，反之越高。 系统吞吐量几个重要参数：QPS（TPS）、并发数、响应时间 QPS（TPS）

一、概述 Spring Integration Kafka 是基于 Apache Kafka 和 Spring Integration 来集成Kafka，对开发配置提供了方便。 二、配置 1、spring-kafka-consumer.xml <?xml version= "1.0" encoding= "UTF-8" ?> <beans xmlns= "http://www.springframework.org/schema/beans" xmlns:xsi= "http://www.w3.org/2001/XMLSchema-instance" xmlns: int = "http://www.springframework.org/schema/integration" xmlns: int -kafka= "http://www.springframework.org/schema/integration/kafka" xmlns:task= "http://www.springframework.org/schema/task" xsi:schemaLocation="http: //www.springframework.org/schema/integration/kafka http: //www.springframework.org/schema

一、kafka基础介绍 Kafka是最初由Linkedin公司开发，是一个分布式、支持分区的（partition）、多副本的（replica），基于zookeeper协调的分布式消息系统，它的最大的特性就是可以实时的处理大量数据以满足各种需求场景：比如基于hadoop的批处理系统、低延迟的实时系统、storm/Spark流式处理引擎，web/nginx日志、访问日志，消息服务等等，用scala语言编写，Linkedin于2010年贡献给了Apache基金会并成为顶级开源 项目。 kafka是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者规模的网站中的所有动作流数据。这种动作（网页浏览，搜索和其他用户的行动）是在现代网络上的许多社会功能的一个关键因素。这些数据通常是由于吞吐量的要求而通过处理日志和日志聚合来解决。 消息队列的性能好坏，其文件存储机制设计是衡量一个消息队列服务技术水平和最关键指标之一，Kafka可以实现高效文件存储，实际应用效果极好。 1.1） kafka名词解释（架构的四个部分） - producer：生产者。 - consumer：消费者。 - topic: 消息以topic为类别记录,Kafka将消息种子(Feed)分门别类,每一类的消息称之为一个主题(Topic)。 - broker：以集群的方式运行,可以由一个或多个服务组成

概述 在本地针对项目的登录接口做了一次简单的压力测试。200并发持续120s，观察吞吐量 运行结束之后，吞吐量是这样的 如图所示，吞吐量波动巨大，完全不正常。现在我们需要去观察一下服务器了 mpstat -P ALL 1* 先看一下cpu的运行情况 可以发现cpu的利用率呈现一种阶梯式递增的趋势，但是负载却不高，说明cpu运行的问题不大 jstat -gcutil 1 1000观察一下内存gc的情况 老年代内存空间不足了，所以导致新生代的对象进不来，频繁fullgc，fullgc的时间又会很长，所以吞吐量一直上不去 检查jvm的内存空间配置 堆区总共只有1g的内存，几乎全部分给了新生代，导致老年代只有5M的可怜空间 修改内存配置 现在来修改一下内存参数，再加入一个并行回收的机制 再次运行脚本，观察TPS和gc频率 这次运行，fullgc的频率变得很低了，而且吞吐量也比较平稳，没有什么大的波动。但是运行到一分半钟的时候，吞吐量出现了塌方式的下降，同时出现了异常。 观察异常日志，发现超过了tomcat最大连接数了 **修改tomcat连接数配置 ，再次运行脚本 这次不像刚刚那要大面积报错了，但是依然有一些异常出现。有一部分是超时，还有一部分是 Software caused connection abort: recv failed 调整一下请求的连接方式，使用java模式

目录 应用程序性能指标 响应时长 并发数 吞吐量 如何提升应用的响应能力 尽可能地压缩响应时长 设置合理的并发数量 在开始之前必须说明，本文力图简单的描述而非学院派解释。 应用程序性能指标 一般地说，单一指标无法勾画出整体水平，我们需要综合使用响应时长、并发数、吞吐量等各种指标描述应用的响应能力。网络上对相关指标有详细描述，这里作出部分解释、补充和示例。 响应时长 响应时长是指系统对请求作出响应的时间，用户对该指标有直观感受。 举例：乘坐火车需要检票，需关照的乘客进站效率低，火车站会开放优先通道以应对。 提问：响应时长可以被无限压缩吗？ 多数请求需要获取各种资源，当发生资源争用时，响应时长无法被压缩。 例如用户需要获取 100万条记录，不讨论内存是否够用的情况，如此多的记录被读取出来，加上网络传输的时间是请求时长的绝对开销。纵然业务再优化，请求时长也不会有更多压缩空间。 DNS 解析、脚本加载，页面渲染等不在本文讨论之列，赶兴趣请以关键字 "从输入页面地址到展示页面信息都发生了些什么" 搜索相关内容。 并发数 并发用户数是指系统可以同时承载的正常使用系统功能的用户的数量。 举例：火车站会在节假日加开更多的检票通道。 提问：增加检票通道就是提高并发数，可以无限增加检票通道吗？ 提升并发数能够减少排队阶段的请求数量，但是面临资源瓶颈时，情况变得不一样。 我们知道检票进站后马上需要安检

如果测试需求出现如下场景，该如何使用Jmeter实现压力测试呢？即Jmeter如何实现多线程组并发测试？也就是Loadrunner中的混合场景测试时，该如何设置并发数？ 可使用吞吐量控制器来实现，先添加需要测试的各个请求。 比如这里的三个接口请求“商铺位置”、“库存”、“押金”。假定接口“商铺位置”、“库存”、“押金”的组合比例为20%：40%：40%。 1.在线程组节点为“商铺位置”请求添加吞吐量控制器： 2.修改名称为sp-20%，也可以不修改，按照业务比例设置吞吐量的值为20，然后把“商品位置”请求拖到该吞吐量控制器节点下： 3.在线程组节点为“库存”请求添加吞吐量控制器，修改名称为kc-40%，按照业务比例设置吞吐量的值为40，然后把“库存”请求拖到该吞吐量控制器节点下： 4.在线程组节点为“押金”请求添加吞吐量控制器，修改名称为yj-40%，按照业务比例设置吞吐量的值为40，然后把“押金”请求拖到该吞吐量控制器节点下： 5.设置总线程为20，运行后查看聚合报告结果如下，满足“商铺位置”：“库存”：“押金”的组合比例为20%：40%：40%。 来源： CSDN 作者： weixin_43802541 链接： https://blog.csdn.net/weixin_43802541/article/details/103820710

目录 应用程序性能指标 响应时长 并发数 吞吐量 如何提升应用的响应能力 尽可能地压缩响应时长 设置合理的并发数量 在开始之前必须说明，本文力图简单的描述而非学院派解释。 应用程序性能指标 一般地说，单一指标无法勾画出整体水平，我们需要综合使用 响应时长 、 并发数 、 吞吐量 等各种指标描述应用的响应能力。网络上对相关指标有详细描述，这里作出部分解释、补充和示例。 响应时长 响应时长是指系统对请求作出响应的时间，用户对该指标有直观感受。 举例：乘坐火车需要检票，需关照的乘客进站效率低，火车站会开放优先通道以应对。 提问：响应时长可以被无限压缩吗？ 多数请求需要获取各种资源，当发生资源争用时，响应时长无法被压缩。 例如用户需要获取 100万条记录，不讨论内存是否够用的情况，如此多的记录被读取出来，加上网络传输的时间是请求时长的绝对开销。纵然业务再优化，请求时长也不会有更多压缩空间。 DNS 解析、脚本加载，页面渲染等不在本文讨论之列，赶兴趣请以关键字 "从输入页面地址到展示页面信息都发生了些什么" 搜索相关内容。 并发数 并发用户数是指系统可以同时承载的正常使用系统功能的用户的数量。 举例：火车站会在节假日加开更多的检票通道。 提问：增加检票通道就是提高并发数，可以无限增加检票通道吗？ 提升并发数能够减少排队阶段的请求数量，但是面临资源瓶颈时，情况变得不一样。

性能的目标 跑得更快吗？是用更少的资源跑得更快。如果不能兼得，我们通常选择跑得更快，这也是大多数时候性能优化的目的，也有些时候性能优化是为了减少资源消耗。 系统性能的定义 1.吞吐量，系统每s能处理的请求数、任务数 2.时延，系统处理一个请求或者任务的耗时 3.并发数，次级指标，同时接入的客户端数量有时也会成为一个考核指标，一般的后台服务会要求支持100-1000区间的并发连接数，而网站会要求支持10K甚至更大的并发数。 时延和吞吐量往往呈现某种正比关系，吞吐量越高，时延趋于越大，当请求超过系统处理能力时，时延趋于无限大。 并且根据实际经验，时延不会是一个稳定的值，而是一个波动范围，计算吞吐量需要计算区间以及百分比 提高吞吐量，时延区间从400us随之增大 更严重的是，当吞吐量达到一定程度，延迟将会剧烈抖动，出现超长时延，如上图的>50ms. 系统性能测试 收集吞吐量和时延 延迟：每个系统都是有硬性要求的，网站可能是1S-5S，后台系统比如消息队列，可能是100us-5ms之间。 测试工具：调整并发数来模拟不同的吞吐量和时延 在测量延迟的时候，既然延迟是一个区间，我们就需要用百分比来衡量，比如60%以上的时延在1-3ms区间，允许小于2%的大于3ms，一旦不满足任何一个百分比区间，都说明系统还需要优化，case是无效的。 性能测试也要经得起时间考验，一个程序只能高速运行10分钟

1 Bytes Throughput Over Time 每秒传输字节吞吐量，表明Jmeter在测试时，随着时间推移发送和接受的字节数 2 Response Codes per Second 每秒返回的响应码，表明Jmeter测试期间，随着时间的推移返回的响应码，从中我们可看到测试期间在哪个时间段内出现了错误。就可以分析在该时间内系统的什么环境因素，导致的错误。 3 Response Latencies Over Time 每秒钟的响应等待时间， 表明Jmeter测试期间，随着时间的推移系统的响应等待时间的变化，也是系统随着时间推移，系统效率的变化。 4 Response Times Distribution 响应时间分布， X轴表示的是响应时间，Y轴表示的是响应次数，F(X,Y)表示系统在某种响应时间内的响应次数是多少，如果在响应时间短的地方，响应次数多，说明系统的效率比较高。 5 Response Times Over Time 每秒钟响应时间，X轴表示的是系统运行的时刻，Y轴表示的是响应时间，F(X,Y)表示系统随着时间的推移，系统的响应时间的变化，可以看出响应时间稳定性 6 Response Times Percentiles 响应时间百分比，X轴表示的是百分比，Y轴表示的是响应时间，F(X,Y)表示低于某个百分比的响应时间，比如有80%的响应低于400ms。 7