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: 
  Note: if no access log message is generated for a request it means that the Gorouter did not receive the request. Access logs are generated for every incoming request.
  
  ## <a id="app_logs"></a>Using application logs to determine where the time is spent in CF
  
  By enhancing the logging for your application to log messages when the request is received and when it is returned, you can determine how much time it took for the application to respond.
  
  Example:
  
  <pre class="terminal">
  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"
  2016-12-14T00:32:32.50-0800 [APP/PROC/WEB/0]OUT app1 finished processing req at [14/12/2016:00:32:32.500 +0000] with "vcap_request_id": "01144146-1e7a-4c77-77ab-49ae3e286fe9"
  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:"-"
  </pre>
  
  Comparing the router access log message from the previous section with the new application logs, we can construct the following timeline:
  
  * `2016-12-14T00:31:32.35` - Gorouter recieved the request
  * `2016-12-14T00:32:32.35` - Application recieved the request
  * `2016-12-14T00:32:32.50` - Application finished processing
  * `2016-12-14T00:33:32.35` - Gorouter finished proccessing request
  
  The timeline indicates that Gorouter took close to 60 seconds to send the request to the application. To verify this, we will compare the response time of sending a request from the router virtual machine (VM) to the app instance through the router proxy: 
  
  1. Log in to the `router` VM using `bosh ssh`.
  1. Use `time` and `curl` to measure the response time of a request to the application through Gorouter. This will bypass the client-network and the load balancer:
  
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
  