QPS和响应时间RT的关系.pptx

服务器端性能优化-提升QPS、RT 关注：CPU、内存、线程 业务平台 小邪1、找到优化的方向 2、QPS/RT---线程(CPU/IO)的关系 3、最佳线程数 4、优化案例说明 5、找到瓶颈 6、线程本身的开销？什么时候需要我们关注，多线程的切换，线程 本身占用的资源，以及线程的资源开销 7、内存瓶颈（FULL GC的停顿） 8、案例说明 9、内存优化方向QPS：Query-per-second，1秒钟内完成的请求数量 RT：Response-time，1个请求完成的时间QPS提升带来什么？ 1.单台服务器资源的充分利用 2.QPS提升1倍，服务器资源减少1半 Detail 现在有236台 ShopSystem 115台，QPS提升一倍，则Detail只要118 台机器，ShopSystem只要58台机器，或者说未来咱们淘宝的流量增加了一倍， detail和shopsystem的机器数量可以保持不变RT提升带来什么？ 1.提高响应速度，提升用户的体验 2.反过来也会提升QPS前言： 做hesper优化期间，发现一个有趣的事情，当时我们一伙人列出了很多优化点， 有节省内存的，有节省CPU的，有节省IO时间的。

性能测试过程中，发现响应时间提升非 常大，从原来的200毫秒提升到了100ms，大喜总结一下有两个关键的改进： 1、多次搜索请求采用了异步IO，串行改并行2、QP的查询结果做缓存但是性能压测的结果QPS却提升很少：45提升到49，为什么？ 继续1、然后删除掉searchAuction.vm里面的所有模板代码，压测QPS几乎没有变化？ 2、增加压测的用户数，发现QPS从49提升到了190？但是响应时间几乎没有变化，还是 100ms左右，为什么？1 2312 3线程线程线程线程12 3线程QPS和线程数的关系1、在性能压测刚开始之前，QPS和线程是互相递增的关系，线程数到了一定数量之后 ，QPS持平，不在上升，并且随着线程数量的增加，QPS开始略有下降，同时响应时间 开始持续上升 图1（hesper压测）：2、单线程的QPS公式，QPS=1000/RT 同一个系统而言，支持的线程数越多，QPS越高，而能够支持线程数量的两个因素是，CPU数量， 和线程等待 （对于单线程，公式QPS=1000/RT永远是正确的，所以线程能支持的越多，QPS越高）最佳线程数量定义：刚好消耗完服务器的瓶颈资源的临界线程数 公式1：最佳线程数量=((线程等待时间+线程cpu时间)/线程cpu时间) * cpu数量特性： 1、在达到最佳线程数的时候，线程数量继续递增，则QPS不变，而响应时间变长，持续 递增线程数量，则QPS开始下降 2、每个系统都有其最佳线程数量，但是不同状态下，最佳线程数量是会变化的 3、瓶颈资源可以是CPU，可以是内存，可以是锁资源，IO资源最佳线程数的获取1、通过用户慢慢递增来进行性能压测 ，观察压测结果，按照定义很容易获得最佳线程 数量 2、根据公式计算:服务器端最佳线程数量=((线程等待时间+线程cpu时间)/线程cpu时间) * cpu数量 3、单用户压测，查看CPU的消耗，然后直接乘以百分比，再进行压测，一般这个值的附 近略作调整应该很容易得到最佳线程数量。

案例超过最佳线程数-导致资源的竞争以detail系统为例子，我们的apache连接数允许3000个，tomcat线程数允许 200个，而CPU能支持的最佳线程数只有10个左右（CPU 85%以上） ，内存限制的线程数 60个(否则Full GC频繁) 可是CPU不认为自己只有处理10个线程的水平，它会认为自己有处理200个 线程的能力，这是一个问题这个问题存在可能使内存资源成为瓶颈超过最佳线程数，响应时间递增观点：线程多时间消耗长，并不是说我们的代码执行效率下降了，而是资源的竞争，导致线程等待的时间上升了 公式2：平均响应时间 = （并发线程数/最佳线程数） * 最佳线程数的响应时间 例子：超过最佳线程数量之和，线程数量翻倍，响应时间翻倍，QPS不变：下面例子的QPS在1100左右，每次都在 这个值左右，统一使用了1100ü 2个并发，每个申请1M内存，测试结果，qps在1100左右，rt在1.911ms左右 ab -n10000 -c2 http://192.168.211.1:8080/test.jsp?thm=1024000 ü 100个并发，每个申请1M内存，测试结果，qps在1100左右，rt在89ms左右 ab -n10000 -c100 http://192.168.211.1:8080/test.jsp?thm=1024000 ü 200个并发，每个申请1M内存，测试结果，qps在1100左右，rt在170ms左右 ab -n100000 -c200 http://192.168.211.1:8080/test.jsp?thm=1024000最佳线程数是在不断变化的对一个高IO的系统而言，假设CPU时间10ms + IO 时间40ms =总时间 50ms 如果CPU被优化成了5ms，实际总的时间是45ms响应时间从50ms减少到了45ms，成总体时间上看变化不大，单线程的qps从20提升到 22也并不明显，但是实际上由于CPU时间减少了一半，线程数量几乎可以翻番，QPS也 几乎可以提升1倍 反过来如果由于IO时间从40ms变成了80ms，则总时间变成了90ms，总体时间从50ms 提升到了90ms，此时最佳线程数量几乎翻倍，QPS几乎没有什么变化。

我们的系统由于依赖的系统响应时间发生变化，会导致系统本身最佳线程数量的变化 ，这给系统线程资源的分配造成了难度QPS和响应时间RT的关系1、对于大部分的web系统，响应时间RT一般由CPU执行时间，线程等待时间 （IO等待，sleep，wait）时间组成如，hesper由 io-cpu-io-wait-cpu-io组成 表明上看，QPS和RT应该是反比例关系？满足，公式3：QPS=1000ms/RT 如图1：2、 在实际环境中RT和QPS并不是非常直接的反比例关系 实际测试发现，RT的两个时间对QPS的影响并不一样CPU的执行 时间减少，对QPS有实质的提升（线性），IO时间的减少，对QPS提升不明 显所以在高IO的系统，QPS和RT的关系如图2RTQPS图1 单线 程 or 纯CPU多线程图2 高IO线程RTQPS验证案例下面案例用来说明3个事情 1、最佳线程数经常变化 2、CPU的优化直接对QPS贡献 3、远程服务时间的缩短对RT贡献最大案例 ----关注QPS-RT的变化例子简介：通过CPU和IO的测试模型，观察CPU和IO时间消耗变化，而带来的QPS和RT的变化1、准备资源 3台linux服务器（保证服务器的资源不会互相干扰，服务器硬件情况） a、压测服务器（安装了AB 工具） 4CPU b、被压测的主程序部署的服务器 （安装了tomcat和jdk ）2 CPU c、主程序服务器会有IO请求到这台服务器 （安装了tomcat和jdk ）2CPU2个jsp页面，分别是perf.jsp和iowait.jsp （perf.war）压测 server被压测 server Perf.jspIO请求 server Iowait.jspCPU时间 10IO时间90Perf.jsp“); %>“); %>iowait.jsp“); %>硬件配置情况机器1： 处理perf.jsp页面 CPU 2个 CPU参数 model name : Intel(R) Xeon(R) CPU 5120 @ 1.86GHz stepping : 6 cpu MHz : 1862.650 cache size : 4096 KBtomcat配置了jvm的参数 JAVA_OPTS=“-Xms256m -Xmx256m -Xss1024K - Djava.library.path=/root/jnicache/cachemap/cachemap-0.1/src“ 其他默认配置机器2：处理iowait.jsp页面 2个CPU model name : Intel(R) Xeon(R) CPU E5320 @ 1.86GHz stepping : 11 cpu MHz : 1861.916 cache size : 64 KB tomcat配置了jvm参数 JAVA_OPTS=“-Xms256m -Xmx256m -Xss1024K - Djava.library.path=/root/jnicache/cachemap/cachemap-0.1/src“ 其他默认配置性能压测机器 CPU 4个 CPU参数： model name : Intel(R) Xeon(TM) CPU 3.20GHz stepping : 10 cpu MHz : 3192.783 cache size : 2048 KB测试工具：AB案例-基准测试1、进行ab压测 ab -n10000 -c20 http://192.168.211.1:8080/perf/perf.jsp?cpuc=30000 %>堆内存的分配例子1：单线程情况下，只要eden区的内存大小 > 线程每次申请的内存大小 tomcat中jvm的配置：JAVA_OPTS=-Xms256m -Xmx256m -Xss128k -XX:MaxTenuringThreshold=15 堆内存分布：Eden 15.812M S0 S1 1.938M Old 236.312M AB请求：ab -n1000 -c1 “http://localhost/perf/memory2.jsp?m=15 还有一些web框架本身的上下文Map，尽量不要放入大数据量的对象ü 2、对象创建到可回收的时间要尽可能短 //大内存数据 1. Object xxx = new XXX(); // 执行消耗时间的工作，包括线程等待或者CPU消耗 2. Object yyy = method.invoke();//耗时10ms 3.zzz = yyy + xxx; 4.xxx=null; 可以修改成： // 执行消耗时间的工作，包括线程等待或者CPU消耗 1. Object yyy = method.invoke();//耗时10ms //大内存数据 2. Object xxx = new XXX(); 3. zzz = yyy + xxx; 4. xxx= null; ü 3、其他如全局对象，静态对象的数据量要进行控制，不过这种相对比较容易通过压力测试发现问题 ü 4、对于通过网络或者其他第三方获取的数据值，要保持怀疑态度，比如搜索引擎返回的搜索字段的个数，理论 上是一个100以内的值，但是有可能会得到一个你无法想象的值。

创建 XXXMethod.invoke使用xxx创建 XXXMethod.invoke使用xxx此时minorGC要点回顾1、找到优化的方向 提升QPS还是提升RT，这两者的优化思路截然不同 2、QPS的提升，RT的提升 我们知道了QPS的优化必须针对瓶颈进行优化(目前我们的系统瓶颈基本上都应该是CPU)，而响应时间缩短更多依赖减少IO，减少线程等待 ，减少线程数量 公式：平均响应时间 = （并发线程数/最佳线程数） * 最佳线程数的响应时间3、最佳线程数 公式：最佳线程数量=((线程等待时间+线程cpu时间)/线程cpu时间) * cpu数量4、线程 线程是一种有限资源，何时需要关心线程本身的开销 5、服务器需要同时处理大量的连接请求，并且服务器本身依赖其他IO资源，依赖的IO资源的响应时间远远超过服务器的计算时间，并且 IO的响应时间可能变化很大 典型：。