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

  • 时间:
  • 浏览:0

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

是因为 锁的代码是HttpClient的execute法子,该法子在执行的事先,老是在在等待获取HTTP连接,通过查看源代码,发现居然不能 使用连接池,醉了。赶紧加带如下代码:

下单属于写接口,大次责状况下,瓶颈都出在DB里,程序运行本来 时会 在等待DB锁的释放。为了验证你你这种想法,当当他们 都不能 使用Jmeter和jvisualvm来验证一下。

本文作者:王练

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

1、打印下单接口的所有SQL,本来 逐一进行explain操作,看看有不能 全表扫描的话语本来 没用到索引的SQL话语;

为了监控服务器和服务器中JAVA程序运行,当当他们 不能 开启JMX,都不能 在JAVA程序运行启动的事先,加带如下有哪几个参数:

好了,现在当当他们 都不能 使用Jmeter来对下单接口进行压测了。都不能 先用500程序运行并发压,执行时间是1分钟。 

腾讯云Mysql

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

让执行库存操作的程序运行执行事先,赶紧释放行锁。原来 做时会 个风险,本来 库存扣减成功后,下单失败了。不过你你这种状况比较少,本来 当时的下单接口中,大次责业务逻辑时会 前面做好判断了,到达插入订单的代码时,都本来 单独的insert了,除非数据库挂了,不然不需要再次出现下单失败的状况。

好了,到了这地方,当当他们 都不能 回到前面,来出理 库存难题了。本来 老板说,不能大改,本来 让人在reduceSkuStock法子上,再开另一个多 事务。

压测结果发现,下单接口的TPS提高了一倍,CPU也上去了不少,本来 仍然欠缺理想,代码里,应该还有许多的锁。再次做程序运行dump,又发现了另一个多 锁。

重新启动程序运行后,打开本地的(我用的是Window10)jvisualvm,加带JMX配置。配置成功后,都不能 点击程序运行那个tab,本来 当当他们 要做程序运行dump,观察程序运行的执行状况。

负载很低,将程序运行并发调整到5000后,CPU还是上不去,原来 话语,初步都不能 判断,代码里有锁。 通过观察dump文件,发现如下信息:

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

在压测的过程中,做一下程序运行dump,一同利用nmon观察应用服务器CPU的负载状况。

触发你你这种lock的业务代码是reduceSkuStock法子。通过阅读代码,发现reduceSkuStock被包在另一个多 大事务里面。

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

原文链接

你你这种是下单接口的逻辑不能大改的状况下的优化方案,一般来说,库存操作应该是单独的服务,都不能 单独优化的。而单纯的下单逻辑也是都不能 优化的。

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

库存记录通常所处一张独立的库存表,本来 创建订单的法子,是另一个多 大事务,原来 就会是因为 某条库存记录不能当整个createorder()法子执行事先,数据库行锁才会被释放,在你你这种期间,许多程序运行是无法对这条库存记录进行写操作的。本来 当当他们 都不能 在reduceSkuStock()中,再开另一个多 事务,操作完这条库存记录后,立刻释放锁,原来 应该都不能 提高许多性能。为了验证是与与否本来 事务的是因为 是因为 下单接口慢,当当他们 都不能 直接将createOrder()法子的事务加带,再压测一下。

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