Will the history service get unsteady in rolling update of deployment?


I have learned that

  1. front-end service needs to calculate which node the execution belongs to according to
    hash32(executionID) MOD shardCount MOD NodeCount

  2. shardContext contains a lot of runtime data in memory to speed up the read/write of the server.

So my question is when the history service nodes are updated, the number of nodes changes during the process. This will change the assignment of a shard to a different Node, and the memory data needs reconstruction. Will this greatly affect the performance of history service?

I am not sure if my concern is a valid one. And very willing to have different opinions on this quesition.
Thanks :slight_smile:

Yes you may experience increased performance latencies during shard rebalancing until things “settle down”.
Be careful with scaling down history service as more shards being allocated to fewer pods could mean increased history memory cache, so check resources you give your pods to account for that.

I have a question about this. If so, I guess Temporal should be better if run VM instead of K8S?

Not sure I understand the question, can you clarify please?