docs: add worker deployments best practice

docs/best-practices/cloud-access-control.mdx

@@ -4,7 +4,6 @@ title: Managing Temporal Cloud Access Control
 sidebar_label: Managing Cloud Access Control
 description: Best practices for managing access control, permissions, and user management in Temporal Cloud.
 toc_max_heading_level: 4
-hide_table_of_contents: true
 keywords:
   - temporal cloud
   - access control

docs/best-practices/managing-namespace.mdx

@@ -4,7 +4,6 @@ title: Managing a Namespace
 sidebar_label: Managing a Namespace
 description: Best practices for managing Temporal Namespaces including configuration, retention, and optimization strategies.
 toc_max_heading_level: 4
-hide_table_of_contents: true
 keywords:
   - namespace management
   - temporal namespace

docs/best-practices/security-controls.mdx

@@ -4,7 +4,6 @@ title: Security Controls for Temporal Cloud
 sidebar_label: Security Controls for Cloud
 description: Best practices for implementing and managing security controls in Temporal Cloud environments.
 toc_max_heading_level: 4
-hide_table_of_contents: true
 keywords:
   - temporal cloud security
   - security controls

docs/best-practices/worker.mdx

@@ -0,0 +1,81 @@
+---
+title: Worker deployment and performance
+sidebar_label: Worker Deployment and Performance
+description: Best practices for deploying and optimizing Temporal Workers for performance and reliability.
+toc_max_heading_level: 4
+keywords:
+  - temporal worker
+  - worker deployment
+  - performance optimization
+  - best practices
+tags:
+  - Best Practices
+  - Workers
+---
+
+This document outlines best practices for deploying and optimizing Workers to ensure high performance, reliability, and
+scalability.
+
+## Core tenets
+
+[Workers](../encyclopedia/workers/workers.mdx) are the execution layer of Temporal applications. They poll task queues,
+execute Workflows and Activities, and report results back to the Temporal Server. As such, Worker deployments have the
+following core tenets:
+
+- Stateless and ephemeral. Even though Workers retain a cache to increase performance during execution of the same
+  workloads, at their core, workers are stateless processes. All state that your applications rely on for durable
+  execution lives in Temporal. Workers are designed to tolerate restarts and rescheduling.
+
+- Horizontally scalable. The number of workers must be adjustable based on workload demands.
+
+- Observable and tunable. Effective Worker tuning requires various metrics, traces, and logs to be collected and acted
+  on.
+
+These core tenets inform all best practices recommended in the following sections.
+
+## Deployment model
+
+This section covers best practices for Worker deployment models.
+
+### At least two workers per task queue
+
+### Scope each Worker pool to a single application and environment
+
+Because workers must be horizontally scalable, it is best to deploy them in pools. A worker pool is a number of workers
+that run a Temporal Application. We recommend you dedicate each pool to a single application and environment. However,
+one application can have multiple pools.
+
+### Separate Workflow and Activity Worker pools if their resource needs differ significantly
+
+Even within a single Temporal Application, there are often multiple Workflow and Activity types. If your application
+workloads are small and similar, a single Worker pool can handle all types. However, if your application has distinct
+workloads with different resource requirements or scaling characteristics, consider separating them into different
+Worker pools.
+
+### Use one Kubernetes pod per Worker
+
+Because workers are stateless and horizontally scalable, Kubernetes is a natural fit for deploying them. If you use
+Kubernetes to deploy Workers, we recommend using one pod per Worker instance. This approach simplifies resource
+allocation, scaling, and monitoring.
+
+## Resource allocation and monitoring
+
+This section covers best practices for allocating resources to Workers and monitoring their performance.
+
+### Monitor both CPU and memory usage
+
+Worker processes are constrained by both CPU and memory. Monitor both metrics to ensure that Workers have sufficient
+resources to handle their workloads.
+
+TODO: Steps to find out why they are high.
+
+1.
+
+### Latency metrics inform resource allocation
+
+Monitor Worker latency metrics, such as Workflow and Activity task latencies, to identify bottlenecks. High latencies
+
+## Starting points for production worker deployments
+
+While optimal Worker deployment configurations depend on your specific application workloads, the following starting
+points can help you get started:

docs/develop/worker-performance.mdx

@@ -78,14 +78,14 @@ Available slot suppliers include:
 
 ### Worker tuning {#worker-tuning}
 
-**Worker tuning** lets you manage and customize a Worker's runtime performance characteristics.
-They use special types called **Worker tuners** that assign slot suppliers to various Task Types, including Worker, Activity, Nexus, and Local Activity Tasks.
+Worker tuning is the process of defining customized slot suppliers for the different task slots of a Worker to fine-tune its performance.
+You use special types called **Worker tuners** that assign slot suppliers to various Task Types, including Worker, Activity, Nexus, and Local Activity Tasks.
 
-For more on how to configure and use Worker tuners, see [Worker runtime performance tuning](#worker-performance-tuning) below.
+For more on how to configure and use Worker tuners, refer to [Worker runtime performance tuning](#worker-performance-tuning).
 
 :::caution
 
-- Worker tuners supersede the existing `maxConcurrentXXXTask` style Worker options.
+Worker tuners supersede the existing `maxConcurrentXXXTask` style Worker options.
   Using both styles will cause an error at Worker initialization time.
 
 :::
@@ -119,9 +119,10 @@ Temporal Cloud and Temporal Server 1.29.0 and higher have Eager Workflow Start a
 
 :::
 
-Eager Workflow Start is feature that reduces the time it takes to start a Workflow.
-The target use case is short-lived Workflows that interact with other services using Local Activities, ideally initiating this interaction in the first Workflow Task, and deployed close to the Temporal Server.
-These Workflows have a happy path that needs to initiate interactions within low tens of milliseconds, but they also want to take advantage of server-driven retries, and reliable compensation processes, for those less happy days.
+Eager Workflow Start reduces the latency required to initiate a Workflow execution.
+It is recommended for short-lived Workflows that use Local Activities to interact with external services, especially when these interactions are initiated in the first Workflow Task and the Workflow is deployed near the Temporal Server to minimize network delay.
+
+This feature is particularly beneficial for Workflows with a “happy path” that must begin external interactions within tens of milliseconds, while still relying on Temporal’s server-driven retries and compensation mechanisms to ensure reliability in failure scenarios.
 
 **Quick Start**
 

sidebars.js

@@ -628,6 +628,7 @@ module.exports = {
         "best-practices/managing-namespace",
         "best-practices/cloud-access-control",
         "best-practices/security-controls",
+        "best-practices/worker",
       ],
     },
     {

vale/styles/config/vocabularies/Temporal/accept.txt

@@ -2,8 +2,6 @@ Temporal's
 APIs
 Temporal Application
 application
-ensure
-Ensure
 extract
 sample
 samples