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

  • 时间:
  • 浏览:0
  • 来源:uu快3和值_uu快3app_计划师

压测结果发现,下单接口的TPS提高了一倍,CPU也上去了不少,只是仍然严重不足理想,代码里,应该还有很多的锁。再次做应用程序dump,又发现了有有一个 锁。

重新启动应用程序后,打开本地的(我用的是Window10)jvisualvm,上加JMX配置。配置成功后,都时要点击应用程序那个tab,可能亲戚亲戚大家要做应用程序dump,观察应用程序的执行清况 。

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

腾讯云Mysql

触发你这个 lock的业务代码是reduceSkuStock法律土最好的办法。通过阅读代码,发现reduceSkuStock被包在有有一个 大事务上端。

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

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

库存记录通常发生一张独立的库存表,可能创建订单的法律土最好的办法,是有有一个 大事务,只是就会原应 某条库存记录只有当整个createorder()法律土最好的办法执行后后,数据库行锁才会被释放,在你这个 期间,很应用程序是无法对这条库存记录进行写操作的。只是亲戚亲戚大家都时要在reduceSkuStock()中,再开有有一个 事务,操作完这条库存记录后,立刻释放锁,只是应该都时要提高很多性能。为了验证是是是不是是可能事务的原应 原应 下单接口慢,亲戚亲戚大家都时要直接将createOrder()法律土最好的办法的事务上加,再压测一下。

本文作者:王练

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

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

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

好了,到了这地方,亲戚亲戚大家都时要回到前面,来除理库存现象报告 了。可能老板说,只有大改,只是我就在reduceSkuStock法律土最好的办法上,再开有有一个 事务。

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

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

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

原文链接

下单属于写接口,大每种清况 下,瓶颈都出在DB里,应用程序可能也有等待时间DB锁的释放。为了验证你这个 想法,亲戚亲戚大家都时要使用Jmeter和jvisualvm来验证一下。

好了,现在亲戚亲戚大家都时要使用Jmeter来对下单接口进行压测了。都时要先用400应用程序并发压,执行时间是1分钟。 

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

为了监控服务器和服务器中JAVA应用程序,亲戚亲戚大家时要开启JMX,都时要在JAVA应用程序启动的后后,上加如下几个参数:

你这个 是下单接口的逻辑只有大改的清况 下的优化方案,一般来说,库存操作应该是单独的服务,都时要单独优化的。而单纯的下单逻辑也是都时要优化的。

原应 锁的代码是HttpClient的execute法律土最好的办法,该法律土最好的办法在执行的后后,无缘无故等待时间时间获取HTTP连接,通过查看源代码,发现居然只有 使用连接池,醉了。赶紧上加如下代码:

让执行库存操作的应用程序执行后后,赶紧释放行锁。只是做也有个风险,只是库存扣减成功后,下单失败了。不过你这个 清况 比较少,可能当时的下单接口中,大每种业务逻辑也有前面做好判断了,到达插入订单的代码时,就只是单独的insert了,除非数据库挂了,不然我不要 冒出下单失败的清况 。