下单接口调优实战,性能提高10倍

  • 时间:
  • 浏览:0
  • 来源:大发5分快3_极速5分PK10

负载很低,将线程并发调整到400后,CPU还是上不去,然后 句子,初步须要判断,代码里有锁。 通过观察dump文件,发现如下信息:

你你累似 是下单接口的逻辑并能 大改的情形下的优化方案,一般来说,库存操作应该是单独的服务,须要单独优化的。而单纯的下单逻辑也是须要优化的。

再次压测后,发现代码里或者没人锁了。TPS提升了5倍。或者接下来还得做几件事情:

Djava.rmi.server.hostname填写JAVA线程所在服务器的IP地址,-Dcom.sun.management.jmxremote.port=7969是指定JMX监控端口的,这里是7969。

在开发环境下,经过调优后,下单接口的TPS提升了3倍左右,当然或者开发环境的数据库和应用服务器都比较差,也会对TPS有影响的。当时优化然后,在生产上进行了压测,发现TPS提升了10倍。

1、打印下单接口的所有SQL,或者逐一进行explain操作,看看有没人全表扫描的句子或者没用到索引的SQL句子;

腾讯云Mysql

压测结果发现,下单接口的TPS提高了一倍,CPU也上去了不少,或者仍然缺乏理想,代码里,应该还有有些的锁。再次做线程dump,又发现了一一两个 多多锁。

本文作者:王练

为了监控服务器和服务器中JAVA线程,人们歌词 歌词 人们歌词 须要开启JMX,须要在JAVA线程启动的然后,再加如下好多个参数:

好了,到了这地方,人们歌词 歌词 人们歌词 须要回到前面,来处理库存问题报告 了。或者老板说,并能 大改,或者让你在reduceSkuStock法律法律依据上,再开一一两个 多多事务。

触发你你累似 lock的业务代码是reduceSkuStock法律法律依据。通过阅读代码,发现reduceSkuStock被包在一一两个 多多大事务后面 。

原因分析分析 锁的代码是HttpClient的execute法律法律依据,该法律法律依据在执行的然后,一直等待获取HTTP连接,通过查看源代码,发现果真没人使用连接池,醉了。赶紧再加如下代码:

原文链接

2、观察下单接口执行的过程中,FULL GC发生的次数;

让执行库存操作的线程执行然后,赶紧释放行锁。然后 做全部都是个风险,然后 库存扣减成功后,下单失败了。不过你你累似 情形比较少,或者当时的下单接口中,大每项业务逻辑全部都是前面做好判断了,到达插入订单的代码时,就然后 单独的insert了,除非数据库挂了,不然不想一直一直出现下单失败的情形。

好了,现在人们歌词 歌词 人们歌词 须要使用Jmeter来对下单接口进行压测了。须要先用400线程并发压,执行时间是1分钟。 

腾讯云2核4g的服务器1台

下单属于写接口,大每项情形下,瓶颈都出在DB里,线程或者全部都是等待DB锁的释放。为了验证你你累似 想法,人们歌词 歌词 人们歌词 须要使用Jmeter和jvisualvm来验证一下。

重新启动线程后,打开本地的(我用的是Window10)jvisualvm,再加JMX配置。配置成功后,须要点击线程那个tab,或者人们歌词 歌词 人们歌词 要做线程dump,观察线程的执行情形。

库存记录通常发生一张独立的库存表,或者创建订单的法律法律依据,是一一两个 多多大事务,然后 就会原因分析分析 某条库存记录并能并能 当整个createorder()法律法律依据执行然后,数据库行锁才会被释放,在你你累似 期间,有些线程是无法对这条库存记录进行写操作的。或者人们歌词 歌词 人们歌词 须要在reduceSkuStock()中,再开一一两个 多多事务,操作完这条库存记录后,立刻释放锁,然后 应该须要提高有些性能。为了验证与非 或者事务的原因分析分析 原因分析分析 下单接口慢,人们歌词 歌词 人们歌词 须要直接将createOrder()法律法律依据的事务再加,再压测一下。

3、增加应用的MYSQL连接数;

在压测的过程中,做一下线程dump,一块儿利用nmon观察应用服务器CPU的负载情形。

本文来自云栖社区商务商务合作伙伴“开源中国”