将cat接口性能优化用于Java应用程序监视

　　1. 为什么要优化接口性能？

　　1. 用户体验差: 接口访问速度慢. 如果打开页面需要花费几秒钟，则用户可能会关闭页面并在页面未完全打开时离开，从而导致用户丢失. 通过性能优化，减少了服务器响应时间. ，可以改善用户体验并减少用户流失.

　　2. 雪崩效应: 接口访问速度慢会带来雪崩效应. 在微服务时代，功能页面可能需要调用多个服务接口. 如果某个接口响应缓慢，将导致服务调用此接口. 它也变得非常慢，最终将导致所有服务整体上变慢.

　　2，什么样的界面值得优化

　　1. 频繁调用且调用时间长的接口值得优化. 接口a被调用10,000次，平均通话时间为500毫秒，接口b被调用10次，平均通话时间为3秒. 优化接口a，假设从500ms到300ms进行了优化，每次节省200ms，则总体优化时间为200万毫秒. 优化接口b，即使从3秒优化到100ms，总的优化时间也只有29000毫秒. 在这种情况下，建议对接口a进行优化，这将更具成本效益并且更值得优化.

　　2. 呼叫数量很少，但是每个呼叫都是异常的（例如，超时后没有返回）. 这种接口也必须进行优化.

　　3. 如何使用cat定位需要优化的界面

　　1. 选择一个具有成本效益的界面（交易）

　　如上图所示，选择了缓存服务应用程序. CacheService.mutliExecute被最频繁地调用，具有720,000个调用和相对较长的调用持续时间，可以用作优化的接口.

　　2. 按条件过滤，提供Long-url，Long sql，Long sevice和Long call过滤条件，可以将它们自己组合以调整时间长度. （问题）

　　3. 通话错误，必须进行修改和处理（问题）

　　4. 如何优化界面

　　1. 查看调用链，找到哪个方法调用花费很长时间

　　通过上图，发现接口中存在循环调用. 优化计划: 调用批处理操作界面以减少接口调用次数.

　　2. 缓慢的SQL优化方法

　　第一步: 解释查看sql执行计划以确认sql是否已被索引.

　　步骤2: 确认数据库表是否已建立索引. 如果没有索引，则创建一个合适的索引，并保持最左边的原则.

　　第3步: 如果有索引，则没有索引，分析原因

　　步骤4: 如果SQL转到索引，它仍然非常慢，请缓存中间结果（异构中间表或将结果缓存在redis中）

　　具体的优化示例:

　　1. 在清单查询接口中，数据库表具有索引，但未使用该索引，因为数据库表的属性类型为varchar，在sql中使用in，但是在传递参数时使用数字类型，这会导致数据发生类型转换，导致没有索引. 优化计划，修改参数传输类型，使用字符串传输参数，优化后从300ms减少到60ms. （如果数据库是数字类型，并且参数使用字符串类型，即使发生类型转换，索引仍然可以使用，这很奇怪）. 在sql中用作多条件查询，有时可以对其进行索引，而有时则不能对其进行索引. 当in中只有一个值时，肯定会对其进行索引. 当查询结果在in中达到所有记录的一定比例时，将不获取索引.

　　2. 大表分页优化，定时任务，需要查询大表分页时，可以使用子查询进行优化. 示例: 商品表中有100万条记录，商品的销售需要每天定期更新. 通常的做法是使用多个线程，每个线程处理200个数据

　　select * from item limit 900000，200

　　执行的时间越晚，时间就越长，因为mysql需要找到前900,000条记录，然后再获取下200条数据. 因为没有索引，所以它会变慢.

　　优化计划一: 使用子查询

　　select * from item i,(select id from item limit 900000,200) as g where g.id = i.id

　　由于可以获取索引，并且子查询使用覆盖索引，因此无需执行第二次查询，从而可以提高查询速度.

　　优化计划2: 主键ID间隔方法

　　先决条件: 表结构中有一个自动增加的主键. 取表的最小值和最大值，将这两个值划分为段，每个线程处理一个间隔. 该查询可以使用主键索引.

　　select * from item where id in (1,2,3,4,5,..200)

　　3.jvm优化

　　查询库存优化后，获取索引后，确实更快. 我通过cat发现库存服务有两个应用程序实例. 一个实例具有非常快的界面，而一个实例却非常慢. 速度较慢的是通过猫的心跳发现的. 完整的gc存在于机器上，而完整的gc偶尔会发生一次.

　　查看jvm的Gc命令

　　jstat -gcutil pid 2000

　　如果存在大量的YGC，则可以使用jmap命令定位创建了哪些对象，然后优化代码以最小化对象的创建. 或调整jvm参数以增加Eden区域的大小. 如果存在大量fullGC，则应注意这种情况，因为fullGC会花费很长时间并且严重影响性能，因此需要调整jvm参数.

　　jmap -histo pid | grep com.galaxy（包路径）

　　top命令查看CPU，内存等的使用情况.

　　top

　　CPU使用了过高的优化方案

　　首先显示线程列表:

　　ps -mp pid -o THREAD,tid,time

　　找到最耗时的线程28802，它占用了将近两个小时的CPU时间！

　　接下来，将所需的线程ID转换为十六进制格式:

　　printf "%x\n" tid

　　最后打印线程堆栈信息:

　　jstack pid |grep tid -A 30

　　无法获得数据库连接

　　可能是数据库正在执行表结构的修改并导致表被锁定

　　select * from information_schema.processlist where db = 'item'and state like '%lock%'

　　需要终止检测到的进程. 您可以使用命令

　　kill 进程Id

　　无法获得redis连接，可能在某些地方未释放该连接，可以使用jstack命令定位

　　jstack –l pid > jstack.txt

　　下载jstack.txt进行分析，然后搜索Lock关键字，这可以方便地定位问题. 最好的方法是统一封装连接的操作，使开发人员没有机会犯错误.