如何在Cloudfoundry中定位应用程序的慢请求？

运行在Cloudfoundry中的Apps一般经过如下组件:

在企业环境中，除了Cloudfoundry中原生的HAproxy组件，上一层会添加基础设施负载均衡或者软负载（如AWS的LB，自建的Nginx、自有DC的F5、A10等）,无论处于哪种情况，我们可以使用time命令来计算整个请求的大概时间层次，请求的同时使用cf logs appsname查看输出日志，当然，apps中也需要添加相应的日志用于反应出自身处理的实际时长，对比完这些时间后，就可以判断出访问慢的根本原因是在CF外部，还是GoRouter亦或是应用的本身。

下面我们用articulate这个app来模拟判断的步骤：

1.使用time命令来获取整个访问的时间,运行time curl -v https://articulate-cyanic-riempie.cfapps.yourdomain.com -k（如果不带https，取消掉-k参数）：

通过上图可以看到real time花费了4秒左右，这是在我开了迅雷占用本机带宽的情况下访问的结果，如你的时间比4秒更长，可能就是你本机网络的原因了。接下来，缩小查找范围，看看在cloud foundry中的请求日志。

2.使用cf logs命令，可以看到从Gorouter到应用的访问响应时间

上图第一个黄色框中代表Gorouter接收到请求的时间和Grouter的vm-id,第二个代表整个请求在Cloudfoundry中的处理时间，为了更清楚的了解在哪一步消耗了大量的时间，可以在应用中添加更详细的日志,推荐的时间轴名称如下：

 i.Gorouter 接收请求

 ii.APP接收请求

iii.APP处理完请求

iv.Gorouter处理完请求

当上述时间存在较大差异时，说明Gorouter和APP之间存在延迟或者网络延迟。

3.为了确认到底是因为Gorouter自身的延迟还是它与应用之间的延迟，可以使用如下两种方式去确认：

i.通过Gorouter代理访问apps

ii.直接访问apps

操作步骤如下：

i.登录到Gorouter所在的Vm

ii.执行

iii.获取app运行在哪台cell上

iv.直接访问host

time curl http://192.168.16.21:61026

如果两种方式返回的时间接近，说明Gorouter和Diego_cell之间有延迟；如果访问Gorouter的时间比直接访问的时间要长很多，说明Gorouter存在问题。

4.Gorouter存在延迟的可能性

i.Gorouter vm loadaverage 过高，导致进来的请求缓慢

ii.APP的处理时间过长，导致Gorouter不断的发送新的请求

5.建议

i.监控Gorouter的cpu 负载，如果cpu负载达到70%以上，Gorouter处理请求的速度会降低，如果cpu 负载持续70%以上，可以增加一台instance.

ii.通过Firehorse监控所有的Gorouter的延迟，注意不要监控延迟的均值，要监控每个Router的独立值

iii.使用基调、OneApm、博睿等监控延迟和在线时间

iv.部署第三方service或者nozzle监控Gorouter的：

  a.cpu使用率

  b.访问延迟

  c.每秒请求数