服务器端性能优化-提升QPSRT.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左右，为什么？线程11线程线程线程1 2322线程33QPS和线程数的关系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左右，每次都在这个值左右，统一使用了11002个并发，每个申请1M内存，测试结果，qps在1100左右，rt在1.911ms左右 ab -n10000 -c2 :8080/test.jsp?thm=1024000100个并发，每个申请1M内存，测试结果，qps在1100左右，rt在89ms左右ab -n10000 -c100 :8080/test.jsp?thm=1024000200个并发，每个申请1M内存，测试结果，qps在1100左右，rt在170ms左右ab -n100000 -c200 :8080/test.jsp?thm=1024000最佳线程数是在不断变化的对一个高IO的系统而言，假设CPU时间10ms + IO 时间40ms =总时间 50ms如果CPU