经常会收到用户反馈在使用RDS的过程中出现卡慢，闪断地情况，当出现此类问题的时候，首先我们要进行一下测试，看看问题出现在哪一个阶段，RDS给到用户的是一个DNS地址，其实他包括三个阶段：DNS–>VIP–>DB
我们可以在本地的应用服务器（VM）上通过简单的ping命令，或者数据库的客户端去不断的连接测试RDS，来获取每次连接RDS的响应时间（RT）。在正常情况下RT应该小于20ms以内，如果超出10ms，则表明了RDS的网络链路出现了异常，这个时候我们就需要去排查一下是在哪里出现了问题：
（1） 当DNS链路服务出现问题：
当我们测试出DNS的连接比较耗时，而使用vip连接正常的时候，则表明DNS解析比较耗时，此时的问题则出现在了DNS服务上面，这个时候可以尝试换用其它的DNS服务器，或者启用DNS缓存服务，或者暂时在hosts文件中绑定DNS和IP地址，等DNS服务恢复正常后在取消绑定（我们强烈建议在正常情况下不要绑定RDS的DNS和IP地址，或者直接使用IP地址进行访问，因为RDS的IP地址可能会发生改变，绑定ip或者直连ip的方式会导致RDS访问出错）；
（2） 当VIP 链路出现问题：
当我们测试超出DNS连接比较耗时，同时使用vip连接也比较耗时的时候，则表明RDS的VIP链路出现了异常，这个时候可以提交RDS的工单，让后端的人员进行排查。
（3） 正常情况下的链路表现：
正常情况下，通过DNS或者vip的方式去连接RDS，RT应该在20ms以下。
案例分析一：
用户应用程序从凌晨0:05左右突然开始出现连接RDS超时，RDS，ECS的cpu，网络，io负载都不高，已经影响用户的正常使用，用户的报错截图：
第一步：获取链路RT
为了验证用户所说的APP连接RDS出现连接超时的情况，我们需要部署监控，看看监控中是否与应用中的超时时间一致，于是在用户app以及我们的一台vm上部署sqlping，用于实时探测用户的rds是否存在连接超时的情况：
用户端的APPàRDS测试：（DNS连接）
在我们自己vm上部署的探测测试：（DNS连接）
可以看到无论从用户本地的app环境去连接RDS，还是从我们自己的vm去连接RDS，都是非常快的，没有出现过超时：所以链路上是没有问题的；
最后建议用户从业务上去排查是否存在异常，最终定位应用异常导致。
案例分析二：
用户反馈实例出现写入速度过慢.写入速度不如正常状态下1/10.
排查用户的RDS，ECS的cpu，io负载都不高，但在数据库中发现了有network io的等待，是不是网络出现了异常，所以这个时候需要测试正常的一次连接RDS需要消耗多久的时间，通过SQLping发现了重要线索：
用户在3台不同的vm上去连接测试RDS，发现都出现了大量的连接时间高或者超时，证明了RDS的链路上确实存在了问题,这个时候你可以提工单进行反馈；进一步去探测DB节点的RT，结果发现在后端的DB服务器上出现了异常，最终定位问题在后端的物理服务器上硬件出现了问题，在替换硬件后问题得以解决。