`

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

 
阅读更多

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

 

1        接口名称: 获取列表

1.1      压测现象:单台tps700多,应用cpu高负载

  1.1.1        问题分析:

    旧框架,平均响应时间长,应用CPU高,程序内部有大量的bean到map到json之间的转换,修改数据库连接数后,tps没有提升。

  1.1.2        改进措施:

    重构系统,用mybatis替代之前的dao操作,减少bean-map-json之间的内部数据转换,减少程序内部的无用操作。

  1.1.3        改进效果:

    tps改进后能到3000左右,有较大提升,但压测时应用cpu几乎跑满,还有改善空间。

1.2      压测现象:数据库资源利用率高

  1.2.1        问题分析:

    单台应用,数据库资源cpu都能到50%,10台tomcat在1万并发下数据库cpu跑满,load值700多,但db的qps也不过11554,并不算多,因此怀疑是sql执行耗费了cpu,可能是某条sql没有按索引查找或者索引失效。

  1.2.2        改进措施:

    查看SQL文件发现如下sql:select count(1)  from orders where order_status_id !=40 ,将其改为select order_id from orders  然后通过程序把order_status_id!=40的过滤掉。通过list.size()来获取。order_status_id即使加了索引,由于是!=比较,所以不会去按索引查找,导致cpu高

  1.2.3        改进效果:

    相同环境下(1台nginx,10台tomcat,1000并发),tps由3000变成3727,略有增长,但是db的cpu明显下降,变为30%,效果明显

1.3      压测现象:1N15T ,tps4552;10N15T,tps9608

  1.3.1        问题分析:

    后端都是15台tomcat,前端1台nginx时tps为4552,通过lvs挂10台nginx时为9608,增长不明显,其nginx和tomcat都压力不大,集群结果不合理,怀疑是nginx转发配置的问题;

  1.3.2        改进措施:

    未进一步改进:可能是需要调整nginx的参数,之前发现过nginx不同的配置对后端集群环境的tps影响很大

  1.3.3        改进效果:

 

 

2        接口名称: 信息查询接口

2.1      压测现象:单台tps2000多,应用cpu高,db的qps15000左右

  2.1.1        问题分析:

    旧框架,程序内部有很多Bo-map-json相互的转换

  2.1.2        改进措施:

    删除冗余代码、更换连接池包,使用mybatis

  2.1.3        改进效果:

    Tps由2000多增长为8000多,db的qps为9000左右,优化后压测应用的cpu占用高,几乎跑满。

 

2.2      压测现象:数据库无压力,应用增加多台后tps不变

  2.2.1        问题分析:

    1N1T和1N10T的tps一样,都为5000,增大并发时错误数增多,应用cpu耗费70%,db无压力,nginx单台通过ss –s 发现端口占满,即nginx到tomcat之间转发的连接端口time-wait状态6万多。Nginx存在瓶颈。

  2.2.2        改进措施:

    调优nginx参数,将短连接改为长连接

  2.2.3        改进效果:

    1N3T的tps能到17376,tomat的cpu压力84%,db的qps18000,cpu69%,应用的资源基本使用到量。

 

 

3        接口名称: 获取详情

3.1      压测现象:单台应用tps2600,10台tomcat才3700

  3.1.1        问题分析:

  增加应用服务器,tps增长不明显,且nginx、tomcat、db的负载都不高,说明服务器本身不是瓶颈,考虑是不是网络的问题,通过监控网卡包流量发现网络数据跑满,因为此接口会有大量数据的输出,因此瓶颈在网络上。另外,测试过程中发现redis有报错,redis服务器是虚机,可能服务能力有限。

  3.1.2        改进措施:

    开启tomcat的gzip压缩。

  3.1.3        改进效果:

    同等并发下(1台nginx,10台tomcat,1000并发),tps由3727增长到10022,增长了近3倍,效果显著。

 

3.2      压测现象:1N10T集群下nginx参数调优对tps提升效果明显

  3.2.1        问题分析:

    经过tomcat的启用gzip后,1N10T下tps为10022,需进一步提升。

  3.2.2        改进措施:

    优化nginx:

    l  nginx日志关闭

    l  nginx进程数量worker,由24改为16

    l  nginx  keepalive数量由256改为2048

  3.2.3        改进效果:

  Tps由10022提升为13270。

3.1      压测现象:1N5T和1N10T的tps相差不大

  3.1.1        问题分析:

    1N10T的tps为1万3千多,1N5T的tps为1万2千多,相差不大,应用的tomcat资源利用没满,cpu为65%,Db的QPS已经到2万多了,单台服务器db基本上到量了,因此再增加应用也没效果,只会导致响应的时间变长。

  3.1.2        改进措施:

    单台db已经无法改进了,要不提升服务器硬件,要不读写分离。

  3.1.3        改进效果:

 

 

4        接口名称: 促销

4.1      压测现象:通过redis存取数据,tps才1000多,CPU 有压力

  4.1.1        问题分析:

    此接口通过redis取数据,tps不高才1000多,但cpu占用了80%,说明程序内部有大量序列化反序列化的操作,可能是json序列化的问题。

  4.1.2        改进措施:

    将net.sf.json改成alibaba的fastjson。

  4.1.3        改进效果:

    同等并发条件下tps由1000多提升为5000多,提高了近5倍。

  

4.1      压测现象:参数多时tps下降明显

  4.1.1        问题分析:

    此接口根据参数从redis中获取数据,每个参数与redis交互一次,当一组参数时tps5133,五组参数时tps1169,多次交互影响了处理性能。

  4.1.2        改进措施:

    将从redis获取数据的get改为mget,减少交互次数。

  4.1.3        改进效果:

    五组参数时1N3T压测TPS9707,据此估算即使是单台tomcat,tps也能有三四千,性能比单次get的调用方式提升了3,4倍。

4.2      压测现象:1N3T tps1万多,在增大tomcat可能tps增长不会明显

  4.2.1        问题分析:

    此处说的是可能,因为nginx服务器的cpu虽然不高,但pps已经800多k,此时应该是nginx的服务器网络流量成为了瓶颈。(只是猜测)

  4.2.2        改进措施:

    可以增加多台nginx负载,前端加lvs

  4.2.3        改进效果:

 

 

5        接口名称: 追踪接口

5.1      压测现象:1N10T的tps低于1N3T的tps

  5.1.1        问题分析:

    1N3T在2000并发下tps为9849,此时db的qps为90000,CPU80%,将tomcat增到10台,5000并发下,tps为7813,db的qps为19000,cpu75%,load 1,说明压力增大情况下db的压力反而下来了,注意到nginx服务器的网卡流量达到885M,说明是压力过大情况下,网络满了,发生丢包,导致db端压力反而下来了。

  5.1.2        改进措施:

    注意压测情况下部分接口由于数据量传输较大,会出现网络瓶颈。

  5.1.3        改进效果:

 

6        接口名称: 回填接口

6.1      压测现象:tps不到500,db的qps3500

  6.1.1        问题分析:

    虽然缺少应用的cpu及db的cpu利用率数据,较低的tps应该是应用的瓶颈,且需要关注是不是db在处理查询的时候缓慢。

  6.1.2        改进措施:

    1.连接池由dbcp改为hikar;

    2.减少了日志打印输出

    3.sql优化,将部分条件过滤改为在java代码中执行

  6.1.3        改进效果:

  Tps由不到500增长为1300多。

7        接口名称: 券查询

7.1      压测现象:集群结果与单台应用结果相比不合理

  7.1.1        问题分析:

    查看是否存在瓶颈资源,可以看到5台tomcat集群下,tps为9952,但db的qps为5-6万,cpu利用率为37%,说明对数据库进行了大量的主键或索引查询,一般单台db的qps也就4万左右,再增加应用的集群数量,对tps也不会有太大影响。

  7.1.2        改进措施:

    可以考虑分库

  7.1.3        改进效果:

 

8        接口名称: 推荐

8.1      压测现象:nginx长短连接差异

  8.1.1        问题分析:

    18nginx,2tomcat时tps8100,此时应用服务器的端口数满, 一般来说,Nginx短连接在高并发下容易导致端口占满的问题。

  8.1.2        改进措施:

    将nginx改为长连接

  8.1.3        改进效果:

    tps增长为10733,TPS稳定,起伏减少,但是CPU耗尽。说明cpu打满了,此时如果还要优化就的进行代码调优了。

9        接口名称: 查询2

9.1      压测现象:18N20T的tps才6842

  9.1.1        问题分析:

    18台nginx,20台tomcat,tps才6842,此时应用cpu利用率85%,说明cpu存在瓶颈,但检查此接口并未做大计算量的工作,有可能是日志的级别问题,cpu在频繁的打日志。

  9.1.2        改进措施:

    将日志级别由debug级改为info级

  9.1.3        改进效果:

    同等环境tps由6842增长为23592.坑爹的生产环境debug日志级别。

分享到:
评论

相关推荐

    MySQL性能调优与架构设计(pdf高清)

    MySQL性能调优与架构设计MySQL性能调优与架构设计MySQL性能调优与架构设计MySQL性能调优与架构设计MySQL性能调优与架构设计MySQL性能调优与架构设计MySQL性能调优与架构设计MySQL性能调优与架构设计

    MySQL性能调优与架构设计.pdf

    性能优化篇从影响 MySQL 数据库应用系统性能的因素开始,针对性地对各个影响因素进行调优分析。如 MySQL Schema 设计的技巧,Query 语句的性能优化方式方法及MySQL Server中SQL层和存储引擎层的优化思路。同时还分析...

    阿里巴巴Java性能调优实战(2021华山版)

    模块二主要讲解 Java 编程性能调优,包括基础的数据类型、容器在实际应用场景中的调优,以及现在互联网系统架构中比较重要的网络通信调优。 模块三:多线程性能调优 模块三主要讲解多线程性能调优,包括多线程编程...

    天河三号原型机分布式并行深度神经网络性能评测及调优.pdf

    【天河三号原型机分布式并行深度神经网络性能评测及调优】 天河三号原型机是中国自主研发的超级计算机,设计目标峰值性能达到百亿亿次级别,具有强大的计算能力,为深度学习领域的研究提供了广阔的平台。深度神经...

    分布式存储Ceph架构与性能调优实践.pdf

    下面将对Ceph架构与性能调优实践进行详细的介绍和分析。 Ceph介绍 Ceph是一个开源的分布式存储系统,它提供了高可用性、高性能和高可扩展性的存储解决方案。Ceph的主要特点是使用对象存储和块存储来存储数据,可以...

    性能测试、分析和调优

    本文旨在深入探讨性能测试、分析及调优的相关知识点,并通过具体案例研究来阐述这些过程对企业级应用的重要性。 #### 一、为何性能如此重要? 在当今快节奏的市场中,用户体验直接影响到客户满意度和品牌忠诚度。...

    大数据各类性能调优

    ### 大数据各类性能调优 #### 12.1 配置原则 在大数据环境中,合理配置资源是实现高效能的关键。以下是一些基本原则: **原则1:CPU核数分配原则** - **数据节点**: 建议预留2~4个核心给操作系统和其他进程(如...

    涨见识!JVM性能监控与调优实战 一线大厂大牛讲师的JVM优化案例与解决方案课程

    JVM性能监控与调优实战课程,作为整篇课程的重中之重,非常值得同学们参考学习。课程前端讲解了JVM的性能监控和调优的概述,对调优的的方法和工具进行讲解学习,让同学们掌握方法,理解知识。课程的中间阶段我们进行...

    2021年MySQL性能调优与架构设计整理.pdf

    ### MySQL性能调优与架构设计的关键知识点 #### 一、MySQL概述 - **定义与特点**:MySQL是一款由MySQL AB公司开发(后被Sun Microsystems收购)的开源数据库管理系统,以其简单高效、可靠性强等特点著称。它是一款...

    高性能服务器架构设计和调优

    ### 高性能服务器架构设计与调优 #### 一、高性能服务器架构设计概述 高性能服务器的设计与优化是一项复杂的工程活动,旨在确保服务器能够快速、稳定地处理大量数据和请求。设计过程中需要综合考虑多种因素,包括...

    性能和调优系列

    3. 调优性能:调优性能是指通过一系列的分析、测试和调整来提高数据库系统的整体性能。调优过程包括系统资源的合理分配、查询优化以及数据库结构的调整。 4. 调优级别:调优可以发生在不同的级别上,包括硬件级别的...

    MySQL性能调优与架构设计

    在性能调优和架构设计方面,MySQL的架构设计主要体现在其各功能模块的组成及其协同工作的原理。了解MySQL各功能模块,包括存储引擎、连接处理、查询解析、优化和缓存等方面,对于性能调优至关重要。MySQL的架构设计...

    MySQL性能调优与架构设计.pdf(文字版,带目录)

    MySQL性能调优与架构设计是数据库管理领域中的一个重要主题,主要关注如何提升MySQL数据库的运行效率,优化查询性能,以及构建高效稳定的数据架构。简朝阳的这本书提供了详细的指南,包括了理论知识和实践技巧,旨在...

    软件性能测试与调优指南.doc

    4.2. 性能调优:根据分析结果调整系统配置、优化代码、改进架构等,以提升性能。 七、持续监控与优化 在性能测试和调优后,需要持续监控系统在实际运行中的性能,定期进行回归测试,确保优化效果的持久性。 总的...

    应用服务架构及性能调优详解

    内容概要:该文档介绍了常见的三种Java应用服务器(JBoss, Tomcat, Jetty)的整体架构及其启动流程,并深入探讨了它们各自的特性与配置要点。此外,文中还详细阐述了应用服务器的关键组件如类加载器(ClassLoader)的...

    MySQL性能调优与架构设计-简朝阳

    《MySQL性能调优与架构设计》是简朝阳的一本专著,主要针对数据库管理员、开发人员和系统架构师,深入探讨了如何优化MySQL数据库的性能并进行合理的架构设计。书中涵盖了多个关键领域,旨在帮助读者提升数据库系统的...

    connections5.5性能调优

    文档中提及了数据库服务器硬件和架构的优化,数据库缓存、预取技术和数据压缩是常见优化手段。其中,DB2数据库的autonomic features(自治特性)如DB2_MINIMIZE_LISTPREFETCH和DB2_SELECTIVITY可以优化查询性能,而...

Global site tag (gtag.js) - Google Analytics