anchor.diff:  
   <%= image_tag("request_lifecycle.png") %>
   
  -## <a id="total-latency"></a> Measuring total round trip time for an application request
  +## <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
  +GET /hello HTTP/1.1
  +Host: app1.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
  +Date: Tue, 14 Dec 2016 00:31:32 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
  +real	2m0.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. 
  +The request to `http://app1.app_domain.com` took aproximately 2 minutes, round-trip. This seems like an unreasonably long time. 
   
   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
  +## <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:33: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.
  +`14/12/2016:00:31:32.348` - 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.
   
  
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: 
  <strong><%= modified_date %></strong>
  
  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
  
  