Clarify which instance runs scheduled events when scaling to multiple instances - #11749
Open
Yornik wants to merge 3 commits into
Open
Clarify which instance runs scheduled events when scaling to multiple instances#11749Yornik wants to merge 3 commits into
Yornik wants to merge 3 commits into
Conversation
The note on this page only described behavior for versions below Mendix 9.12.0, which left the current behavior undefined. Readers scaling to multiple instances could not tell from this page which instance runs scheduled events on a supported version. State the current behavior explicitly, distinguishing legacy scheduled events (cluster leader only) from task queue based scheduled events (arbitrary instance), matching the wording already used in Clustered Mendix Runtime. Also note that the cluster leader can show higher CPU usage as a result, since this is a common source of confusion when looking at per-instance metrics. The pre-9.12.0 note is kept. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Restructure the previous commit to follow the repository style guide. The guidance in the style guide is to keep alerts to 1-2 paragraphs and to avoid lists inside alerts, so the alert is reduced to a single paragraph with no list. Move the point about cluster leader CPU usage out of the alert and into Scaling Notes, next to the existing note about task queue scope, which is where per-instance scaling behavior is already described. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
| * The number of available instances depends on the total memory provided by your cloud resource pack and the memory per instance that you have set. It is not possible to set scaling values that exceed the memory provided by your [cloud resource pack](/developerportal/deploy/mendix-cloud-deploy/#resource-pack). | ||
| * It is not possible for a single instance to use more than 32 GiB of RAM. Some very large cloud resource packs, such as XXXL21 or XXXXL21, provide more than this 32 GiB maximum; to use the full RAM in this case, you need more than one instance. For example, to use 64 GiB of RAM, you must spread the RAM between two or more instances. | ||
| * Consider the functionality that runs inside task queues; think about whether the scope of these task queues should be configured to run in all instances or once per cluster. It is possible to set the [scope of the threads](/refguide/task-queue/#create-queue) per task queue. | ||
| * In addition to handling requests, the [cluster leader](/refguide/clustered-mendix-runtime/#cluster-leader-follower) performs cluster management activities such as removing persisted sessions and cleaning up unreferenced files. It can therefore use more CPU than the other instances, even when incoming traffic is distributed evenly. |
Contributor
There was a problem hiding this comment.
The cluster management activities are run on every node. So this being the sole reason for the increased CPU would be incorrect.
Were you able to verify this statement ?
Review feedback: cluster management activities are picked up by any node in a multi-node environment, not only by the cluster leader, so citing them as the reason for higher CPU on one instance was incorrect. Reword the note to reference legacy scheduled events, which Clustered Mendix Runtime states are executed only on the cluster leader. Phrase it as one example rather than the sole cause. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Contributor
Why do this ? You can modify it a little and say that the legacy schedule event where executed on the leader node. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The alert in the Introduction of Scaling Your Environment in Mendix Cloud described only the behavior for versions below Mendix 9.12.0:
This leaves the behavior on currently supported versions undefined. A reader who scales to two instances and then sees uneven CPU usage between them cannot tell from this page which instance runs scheduled events, or whether the imbalance is expected.
Changes
Alert now states the current behavior, then keeps the historical note. The wording for the current behavior is reused verbatim from Clustered Mendix Runtime so the two pages agree:
Scaling Notes gains one bullet explaining that the cluster leader can use more CPU than other instances, because it also handles cluster management activities. This sits next to the existing task queue scope note, where per-instance scaling behavior is already covered.
Style notes
style-guide/grammar-formatting.md("keep alerts short (1-2 paragraphs)" and avoid lists in alerts). That is why the CPU point went into Scaling Notes rather than expanding the alert.task queue basedis left unhyphenated to match the existing wording in Clustered Mendix Runtime.#cluster-leader-followeranchor were verified to resolve; that anchor form is already used incustom-settings/_index.mdand the Azure HA page.For reviewers
The second bullet in Scaling Notes is the one addition that is not lifted directly from existing docs. It is a consequence of the cluster leader duties already documented in Clustered Mendix Runtime, and it is included because per-instance CPU differences are a recurring support question. Happy to drop it if you would rather keep this change purely to the alert.
🤖 Generated with Claude Code