一次简单的接口性能优化

最近公司的一个列表接口改为查询领域实体后，到流量高峰期会崩。

报错信息：​​​​​​​java.net.SocketException:Brokenpipe

通信管道已坏。

查看接口链路追踪

链路追踪可以直观的看出哪些地方用时更久，便于找到问题。

查看接口发现进行了一次RPC查询。RPC接口因为请求超时报错关闭了连接，导致查询接口报错。

RPC接口超时原因：

RPC接口每次循环都进行了多次IO。

因为该项目使用的是ddd的模式，每次对Entity查询都进行多次的数据库查询、RPC查询。

虽然一些查询用了redis缓存，但是每次查询redis还是有请求开销，对于列表每次查询20次，也是不小的性能损耗。

如果改成全部用内存缓存，又会导致内存的爆炸。

感觉列表的查询，并不ddd并不适用。 对于商品列表，最好的方式还是走ES。

进行优化之后，第二天确实没有问题了，但是过了三天之后接口又崩了。

查看项目内存使用情况

在阿里云arms上查看项目内存使用情况，显示虽然分配的内存足够，但是jvm设置的最大内存太小。因此设置-Xmx大小，重启项目，解决。