anchor.diff:  
   <strong><%= modified_date %></strong>
   
  -This topic suggests ways that an operator of Cloud Foundry can determine whether an application or CF system components are the cause for delayed requests to an application.
  +This topic suggests ways that an operator of Cloud Foundry (CF) can determine whether an application or CF system components are the cause for delayed requests to an application.
   
   ## <a id="request-path"></a> Application Request Path
   
  
positive.code: 
  <%= image_tag("request_lifecycle.png") %>
  
  ## <a id="total-latency"></a> Measuring total round trip time for an application request
  
  In the following example we will use the `time` and `curl` commands to connect to a deployed application. 
  
  <pre class="terminal">
  $ time curl -v http://app1.app_domain.com
  
  GET /v2/info HTTP/1.1
  Host: api.app_domain.com
  User-Agent: curl/7.43.0
  Accept: */*
  
  HTTP/1.1 200 OK
  Content-Type: application/json;charset=utf-8
  Date: Tue, 13 Dec 2016 23:28:05 GMT
  Server: nginx
  X-Content-Type-Options: nosniff
  X-Vcap-Request-Id: c30fad28-4972-46eb-7da6-9d07dc79b109
  Content-Length: 602
  hello world!
  real	0m0.707s
  user	0m0.005s
  sys	    0m0.007s
  </pre>
  
  The request to `http://app1.app_domain.com` took aproximately 700ms, round-trip. Depending on your expectations, this may be longer than expected. 
  
  Below we will use this same technique to measure request response times from within Cloud Foundry.
  
  
  
  ## <a id="within-cf"></a> Measuring round-trip within Cloud Foundry
  
  In addition to streaming your application logs the `cf logs` command also displays router access log messages for requests to your application:
  
  <pre class="terminal">
  $ cf logs app1
  
  2016-12-14T00:31:32.35-0800 [RTR/0]      OUT app1.app_domain.com - [14/12/2016:00:31:32.348 +0000] "GET /hello HTTP/1.1" 200 0 60 "-" "HTTPClient/1.0 (2.7.1, ruby 2.3.3 (2016-11-21))" "10.0.4.207:20810" "10.0.48.67:61555" x_forwarded_for:"52.3.107.171" x_forwarded_proto:"http" vcap_request_id:"01144146-1e7a-4c77-77ab-49ae3e286fe9" response_time:120.00641734 app_id:"13ee085e-bdf5-4a48-aaaf-e854a8a975df" app_index:"0" x_b3_traceid:"3595985e7c34536a" x_b3_spanid:"3595985e7c34536a" x_b3_parentspanid:"-"
  2016-12-14T00:32:32.35-0800 [APP/PROC/WEB/0]OUT app1 received request at [14/12/2016:00:32:32.348 +0000] with "vcap_request_id": "01144146-1e7a-4c77-77ab-49ae3e286fe9"
  </pre>
  
  `2016-12-14T00:31:32.35` - This timestamp represents when Gorouter received the request.
  
  `response_time:120.00641734` - This represents the response time in seconds for processing the request by Gorouter, including the round-trip request to the application.
  
  
negative.code: 	$ time curl <span>http<span>://APPLICATION\_IP:APP\_PORT 
  	</pre>
  
  Comparing the results of these two requests, we can determine the slow application request time is due either to network latency between the Gorouter and Diego Cell, or caused by Gorouter processing of requests. 
  
  
  ## <a id="gorouter-latency"></a>Potential causes for increased Gorouter Latency
  * Routers are under heavy load.
  * Applications that take a long time to process requests cause an increase in the number of concurrent threads held open by the Router, reducing capacity to handle requests for other applications.
  
  
  ## <a id="ops-recommendations"></a>Operations Best Practices
  - Monitor CPU load for Gorouters. At high CPU (70%+), latency will increase; if Gorouter CPU reaches this threshold, consider adding another Gorouter instance.
  - Monitor latency of all routers using metrics from the Firehose. Note: do not monitor the average latency across all routers. Instead, monitor them individually on the same graph.
  - Consider using Pingdom against an app on your Cloud Foundry deployment to monitor latency and uptime.
  - Consider enabling access logs on your load balancer. In the same way as we described using Gorouter access log messages above to determine latency from the perspective of the Gorouter, you can compare load balancer logs to identify latency between the load balancer and Gorouter. You can also compare these response times with the client response times to identify latency between client and load balancer.
  - Metrics for Gorouter are available from the firehose, you'll find metrics like
  	- CPU utilization
  	- Latency
  