首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往
  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    互联网常见架构接口压测性能分析及调优手段建议

    常见的互联网架构中,一般都能看到spring+mybatis+mysql+redis搭配的身影,在我所服务的公司亦是如此。一般来说,应用内部的接口都是直接调用的,所谓的面向接口编程,应用间的调用直接调或者通过类似dubbo之类的服务框架来执行,数据格式往往采用json,即统一也方便各数据间做转换和取值,缓存一般使用redis或memcached,存储一些对象或json格式的字符串。对外提供的接口,一般都需要进行压力测试,以便估算其性能,并为后续的调优提供指导方向,以下接口便是在压测过程中出现的各种“奇怪现象”,所谓奇怪,指的是从表象上看与我们正常的逻辑思路不符,但其本质还是我们对压力下程序的表现出来的特征不熟悉,用惯用的知识结构试图去解释,这根本是行不通的。下文是我在一次全面压测过程后对数据进行的分析汇总,其中的现象是很多压测常见的,里面的分析过程及改进措施我认为有很大的参考意义。具体内容如下:(部分接口为了安全我省略了其名称,但不影响我们的分析,另外形如1N3T之类的表示的是1台nginx,3台tomcat,具体的tps数值只是为了说明优化前后的比照,没有实际意义)

    05

    压测TPS_测压管原理

    1. TPS、并发量是什么关系?为什么有的地⽅要⽤TPS?有的地⽅要⽤并发? ⾸先,TPS是⼀个吞吐速度的概念,就是每秒处理多少请求。是衡量系统处理能⼒的指标,⽽往往TPS的最⼤值,并⾮系统资源耗尽的时点,因为TPS和系统资源是⼀个抛物线的关系,就是当资源最优配置时往往是TPS最⾼的时间,当资源耗尽时,往往TPS也是⾮常低的。每个TPS指标都会对应当时的并发量。然后说说并发量,并发量往往是对⼀个系统同时操作的⼈数的,或者说同时产⽣的请求数的预估,来衡量系统的承载能⼒。⾔外之意,这个指标⽬的在于看能否同时承载500个⽤户同时操作?或者 1000个⽤户同时操作? ⼀般来说,内部系统特别喜欢⽤并发量来作为衡量参数,原因是操作⽤户是恒定的,或者说是⽐较确定的⽤户群体,所以并发量特别好预估。但是⽬前互联 ⽹业务或是其他外部系统对接的业务,实际是⽆法确定并发量,所以,⼀般来说 ⽐较容易确定并发数的,使⽤并发数来压测是最能体现系统承载能⼒的。如果不能确定并发数,⼀般来说⽤TPS来衡量,特别是外部系统对接

    05
    领券