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左右，为什么？;QPS和线程数的关系;最佳线程数量;最佳线程数的获取;超过最佳线程数-导致资源的竞争;超过最佳线程数，响应时间递增;最佳线程数是在不断变化的;QPS和响应时间RT的关系;验证案例;案例----关注QPS-RT的变化;Perf.jsp;iowait.jsp;硬件配置情况;案例-基准测试;案例-提升RT能提升QPS？;案例-提升CPU时间能提升QPS？;案例-压测结果汇总;前言解释： 做hesper优化期间，发现一个有趣的事情，当时我们一伙人列出了很多优化点，有节省内存的，有节省CPU的，有节省IO时间的。性能测试过程中，发现响应时间提升非常大，从原来的200毫秒提升到了100ms，大喜。总结一下有两个关键的改进：1、多次搜索请求采用了异步IO，串行改并行，画个图2、QP的查询结果做缓存但是性能压测的结果QPS提升很少：45提升到49，为什么？因为IO并不是瓶颈资源，CPU才是瓶颈资源，减少的IO时间并不能使CPU时间增加，所以瓶颈依旧没有解决，QPS变化很少。继续。。。1、然后删除掉searchAuction.vm里面的所有模板代码，压测QPS几乎没有变化？响应时间略有减少，是90ms左右？ 总QPS=线程数*单个线程的QPS，因为压测的时候没有改变用户数量所以线程数没有变化，而单个线程的QPS=1000ms/rt，显然QPS不变。但是此时如果细心你会发现系统的CPU消耗很低。2、增加压测的用户数，发现QPS从49提升到了190？响应时间几乎没有变化，还是100ms左右？QPS提升得益于模板CPU资源的释放，这里也说明了模板消耗了60%以上的CPU。;线程本身是否会影响QPS;总结：CPU瓶颈下的QPS计算;总结：两种极端的应用;耗时热点查找工具;怎么来提升RT;怎么来提升QPS;内存是否是瓶颈;堆内存的结构;堆内存的分配和回收步骤;堆内存的分配;堆内存的分配;堆内存的分配;堆内存的分配;堆内存的分配;堆内存的分配;堆内存的分配;堆内存的分配;堆内存的分配;每个请求占用多少内存计算;Gc.log;内存优化;要点回顾;Time for QA;性能点;两个和线程相关公式;内存会是瓶颈？;例子;我们的系统需要多少线程;我们的系统需要多少线程;我们的系统需要多少线程;超过最佳线程数，响应时间递增？