anchor.diff:  
   ### How to Scale
   
  -The cf-api-worker pod can safely scale horizontally in all deployments.
  +The `cf-api-worker` pod can safely scale horizontally in all deployments.
   
   ## <a id='clock_and_updater'></a> cf-api-clock and cf-api-deployment-updater
   
  
positive.code: 
  Cloud Controller emits the following metrics:
  
  * `cc_job_queue_length_cc-CF_API_WORKER_POD_NAME` (e.g. `cc_job_queue_length_cc_cf_api_worker_565c45df86_h2nsp`) is continuously growing.
  * `cc_job_queue_length_total` is continuously growing.
  
  #### Heuristic Failures
  
negative.code: 
  Before and after scaling Cloud Controller API pods, you should verify that the Cloud Controller database is not overloaded. All Cloud Controller processes are backed by the same database, so heavy load on the database impacts API performance regardless of the number of Cloud Controllers deployed. Cloud Controller supports both PostgreSQL and MySQL, so there is no specific scaling guidance for the database.
  
  Cloud Controller API pods should primarily be scaled horizontally. Scaling up the number of compute resources requested past one CPU is not effective. This is because Ruby's Global Interpreter Lock (GIL) limits the `cloud_controller_ng` process so that it can only effectively use a single CPU core on a multi-core machine.
  
  <p class='note'><strong>Note:</strong> Since Cloud Controller supports both PostgreSQL and MySQL external databases, there is no absolute guidance on what a healthy database looks like. In general, high database CPU utilization is a good indicator of scaling issues, but always defer to the documentation specific to your database.</p>
  
  ## <a id='cf-api-local-worker'></a> cf-api-local-worker
  
  Known as "local workers," this container is primarily responsible for handling files uploaded to the API pods during `cf push`, such as `packages`, `droplets`, and resource matching.
  
  ### When to Scale
  
  