Hi all, I set up temporal on my own k8s cluster using the official helm chart.
After setting up the cluster, i planned to do a performance test, for that i referred to the benchmark worker repo.
Now the confusing part is, in my k8s namespace there is a “worker” pod, the worker is not configured directly with any task queue, not sure what is the reason why it’s part of the chart.
When i deployed the benchmark performance test i also saw that a specific worker, listening to a specific task queue, was deployed, i will call this “customer worker” since it’s tied to my specific workflows.
My questions are:
what is the purpose of the “worker” pod in temporal helm chart? is it supposed to run internal workflows only and not customer workflows?
i’m using a database for persisting the workflow execution state, the database configuration is set as part of the “worker”, but not on the “customer worker”, how is the state persisted then? is it only at local-node level?
what is the purpose of the “worker” pod in temporal helm chart? is it supposed to run internal workflows only and not customer workflows?
Temporal server is composed of multiple service types (frontend, history, matching, worker).
The worker type (yes its a bit of a confusing naming convention and there are plans to rename this to service-worker iirc) is as you mentioned responsible to run internal system workflows.
When i deployed the benchmark performance test i also saw that a specific worker, listening to a specific task queue, was deployed
This is your worker (sdk worker) that runs your workflow and activity code, so not part of the Temporal server itself.
i’m using a database for persisting the workflow execution state, the database configuration is set as part of the “worker”, but not on the “customer worker”, how is the state persisted then? is it only at local-node level?
Note sure I fully understand your question, Temporal service itself defines two persistence stores, primary and visibility ones. All service types need to be able to talk to these two stores which you configure on service level (your static config).
Temporal workflow executions are fully managed by your Temporal service. Your “customer worker” is part of the workflow execution lifecycle (it communicates with service during workflow execution) but does not play a role in persisting any execution information. That’s the part of Temporal durable execution aspect, as in you can have complete “customer worker” outage and your business executions (your workflows) would still be able to continue and complete after failures.
one related question, if my “customer worker” does not play a role in persisting any execution information, why does the worker type need to be able to talk to the persistence stores?