https://docs.temporal.io/docs/concepts/what-is-a-local-activity/

https://community.temporal.io/t/local-activity-vs-activity/290


A Local Activity is an Activity Execution that executes in the same process as the Workflow Execution that spawns it.
Some Activity Executions are ver short-living and do not need the queuing semantic, flow control, rate limiting, and routing capabilities

The main benefit of Local Activities is that they use less Temporal service resources (e.g. lower state transitions) 
and have much lower latency overhead (because no need to roundtrip to the Cluster) compared to normal Activity Executions. 

Local Activities are subject to shorter durations and a lack of rate limiting.






Here is a sequence of steps to execute a single activity workflow.

1. Workflow is started which adds a workflow task into a workflow task queue.
2. A workflow task is received by a workflow worker listening to the workflow task queue.
3. The workflow task is completed with ScheduleActivityTask command.
4. An activity task is added to an activity task queue.
5. The activity task is received by an activity worker.
6. The activity task is completed by the activity worker.
7. The workflow task is added to the workflow task queue.
8. The workflow task with the result of the activity is received by a workflow worker.
9. The workflow task is completed with CompleteWorkflowExecution command.



Here is a sequence of steps to execute a local activity.

1. Workflow is started which adds a workflow task into a workflow task queue.
2. A workflow task is received by a workflow worker listening to the workflow task queue.
3. A workflow schedules a local activity task into the in-process local activity task queue.
4. Local activity is executed by a local activity worker that listens to the in-process local activity task queue.
5. The local activity task is completed back to the workflow.
6. The workflow task is completed with RecordMarker and CompleteWorkflowExecution commands. The marker command contains the result of the local activity execution.


Note that steps 3, 4, and 5 are in memory of the worker and do not require any DB operations. 
So the number of updates in case of normal activity is 9 versus 3 in case of the local one. 
The difference becomes even more pronounced when multiple activities are executed in parallel.

步骤 3 4 5 不需要数据库操作 
数据库更新次数 9 vs 3  

The advantages of the local activity are clear. Here are the drawbacks:
It works only for short activities that do not exceed the workflow task timeout. It implies that heartbeating is not supported for local activities.
It is not efficient for long retries. Normal activities can be retried practically indefinitely.
Local activity has at least once semantic as a failure of a workflow task would lead to their re-execution.
Local activity extends workflow task execution. While the task is running it cannot react to signals. So it increases the latency for signal handling.

We’ve seen multiple cases when use of local activities without understanding their limitations caused various production issues. 
So my advice is to stick to normal activities unless your use case requires very high throughput and large activity fanouts of very short activities.

大量短任务 高吞吐量 才使用 local activity

In the long term, we plan to implement a mixed model. An activity invocation with a short timeout would start as a local activity, 
but in case of failure changed to a normal activity which is more efficient for long retries.