运行在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.每秒请求数
网友评论