# Lowest achievable latency

**URL:** <https://community.temporal.io/t/lowest-achievable-latency/7990>\
**Category:** Community Support\
**Tags:** general-impl, best-practices\
**Created:** [April 21, 2023, 6:46am UTC](https://community.temporal.io/t/lowest-achievable-latency/7990 "2023-04-21T06:46:13Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![Simon\_Hege](https://sea2.discourse-cdn.com/flex016/user_avatar/community.temporal.io/simon_hege/32/3657_2.png) [@Simon\_Hege](https://community.temporal.io/u/Simon_Hege)\
**Post date:** [April 21, 2023, 6:46am UTC](https://community.temporal.io/t/lowest-achievable-latency/7990/1 "2023-04-21T06:46:13Z")

</div>

Hi  
I’m evaluating the usability of temporal for our application, and I’m interested in performance aspects especially added latency. From other posts, such as [Low latency - Stateless Workflow](https://community.temporal.io/t/low-latency-stateless-workflow/1643), I understood that I should expect tens of milliseconds between steps. Is this correct assumption?  
In a basic workflow (1 activity only logging), local-dev, go sdk, I’m seeing a end-start=200ms. Is it the expected order of magnitude or should I investigate my setup?

Is some documentation available on that topic, on top of [Developer's guide - Worker performance | Temporal Documentation](https://docs.temporal.io/application-development/worker-performance)? Any recommendation for the production setup (is ElasticSearch recommended)?

---

<div class="post-metadata">

**Author:** ![tihomir](https://sea2.discourse-cdn.com/flex016/user_avatar/community.temporal.io/tihomir/32/6580_2.png) [@tihomir](https://community.temporal.io/u/tihomir)\
**Post date:** [April 21, 2023, 3:03pm UTC](https://community.temporal.io/t/lowest-achievable-latency/7990/2 "2023-04-21T15:03:35Z")

</div>

> I’m seeing a end-start=200ms

How are you measuring these latencies? SDK metrics (workflow\_endtoend\_latency metric maybe)?

> local-dev

Do you by chance run load tests with [maru](https://github.com/temporalio/maru)?

I think latencies will highly depend on your cluster setup, persistence latencies, network latencies as well as your worker setup and your workflow/activity code (your use case and how you implement it), so there are many moving parts.

Typically you would run load test and then we can look at sdk and server metrics along side your pod cpu and mem utilizations (on both your workers and service hosts) and try to make improvements.

> Any recommendation for the production setup (is ElasticSearch recommended)?

With server version [1.20.0](https://github.com/temporalio/temporal/releases/tag/v1.20.0) you can also set up advanced visibility with SQL persistence. For large scale deployments using ES might still be useful over sql persistence given your db size tho.

---

<div class="post-metadata">

**Author:** ![bergundy](https://sea2.discourse-cdn.com/flex016/user_avatar/community.temporal.io/bergundy/32/900_2.png) [@bergundy](https://community.temporal.io/u/bergundy)\
**Post date:** [April 21, 2023, 11:26pm UTC](https://community.temporal.io/t/lowest-achievable-latency/7990/3 "2023-04-21T23:26:34Z")

</div>

Also take a look at some optimization you can make on the application side to reduce the E2E latency: [Temporal Community Meetup February, 2023 - YouTube](https://www.youtube.com/watch?v=mTNUjZGTfZk&t=360s)