anchor.diff:  
   The first setting, `api_request_time`, is helpful if you have a sustained high number of transactions.
   The second setting, `api_request_size`, can help if you experience peaks of transactions
  -(a large amount of transactions in a short period of time).
  +(a large number of transactions in a short period of time).
   
   Keep in mind that reducing the value of either setting will cause the agent to send more HTTP requests to the APM Server,
   potentially causing a higher load.
  -
   
   [float]
   [[tuning-max-spans]]
   === Spans per transaction
   
   The average amount of spans per transaction can influence how much time the agent spends in each transaction collecting contextual data for each span,
  -and the the storage space needed in Elasticsearch.
  -In our experience, most usual transactions should have well below 100 spans.
  -In some cases however, the number of spans can explode:
  +and the storage space needed in Elasticsearch.
  +In our experience, most _usual_ transactions should have well below 100 spans.
  +In some cases, however, the number of spans can explode:
   
    * long-running transactions
    * unoptimized code, e.g. doing hundreds of SQL queries in a loop
    
  -To avoid that such edge cases overload both the agent and the APM Server,
  -the agent stops recording spans when a limit is reached.
  +To avoid these edge cases overloading both the agent and the APM Server,
  +the agent stops recording spans when a specified limit is reached.
   You can configure this limit by changing the <<config-transaction-max-spans,`transaction_max_spans`>> setting.
   
  -Another option to reduce overhead of collecting contextual data for spans is to disable collection for very short spans.
  +Another option to reduce the overhead of collecting contextual data for spans is to disable collection for very short spans.
   While this contextual data (specifically, the stack trace) can be very useful to pinpoint where exactly the span is caused in your code,
   it is less interesting for very short spans.
   You can define a minimal threshold for span duration in milliseconds,
   using the <<config-span-frames-min-duration,`span_frames_min_duration`>> setting.
   If a span takes less than this duration, no stack frames will be collected for this span.
   Other contextual information, like the SQL query, will still be available.
  +
  +[float]
  +[[tuning-frame-context]]
  +=== Collecting Frame Context
  +
  +When a stack trace is captured, the agent will also capture several lines of source code around each frame location in the stack trace. This allows the APM UI to give greater insight into where exactly the error or span happens. 
  +
  +There are four settings you can modify to control this behavior:
  +
  +* <<config-source-lines-error-app-frames, `source_lines_error_app_frames`>>
  +* <<config-source-lines-error-library-frames,`source_lines_error_library_frames`>>
  +* <<config-source-lines-span-app-frames,`source_lines_span_app_frames`>>
  +* <<config-source-lines-span-library-frames,`source_lines_span_library_frames`>>
  +
  +As you can see, these settings are divided between app frames, which represent your application code, and library frames, which represent the code of your dependencies. Each of these categories are also split into separate error and span settings. 
  +
  +Reading source files inside a running application can cause a lot of disk I/O, and sending up source lines for each frame will have a network and storage cost that is quite high. Turning down these limits will help prevent excessive memory usage. 
positive.code: [[tuning-sample-rate]]
  === Transaction Sample Rate
  
  The most straight forward way to reduce the overhead of the agent is to tell the agent to do less.
  If you set the <<config-transaction-sample-rate,`transaction_sample_rate`>> to a value below `1.0`,
  the agent will randomly sample only a subset of transactions.
  If a transaction is not sampled, the agent has to do a lot less work,
  as we only record the the name of the transaction, the overall transaction time and the result for unsampled transactions.
  
  [options="header"]
  |============
  
negative.code: === Transaction Queue
  
  To reduce the load on the APM Server, the agent does not send every transaction up as it happens.
  Instead, it queues them up and flushes the queue periodically, or when it reaches a maximum size, using a background thread.
  
  While this reduces the load on the APM Server (and to a certain extent on the agent),
  holding on to the transaction data in a queue uses memory.
  