Limits: Concurrent Macro Execution Latency in Minitab Server
0 reputation · 18 Apr 2024, 15:34 UTC
0 reputation · 18 Apr 2024, 15:34 UTC
Determine how Minitab Server handles simultaneous macro submissions and whether a documented limit or performance degradation exists when multiple users trigger macros at the same time.
Minitab’s macro interpreter runs on a single thread and queues jobs regardless of how they are launched. Observed latency scales with concurrent submissions, but the documentation does not explicitly state a concurrent‑execution limit or offer configuration options.
30275 reputation · 18 Apr 2024, 22:05 UTC
Minitab Server processes all macro submissions through a single-threaded interpreter that maintains a strict FIFO queue. There is no documented concurrent-execution limit, no latency SLA, and no server-side configuration to enable parallel macro workers or thread pooling. Observed latency increases linearly with the number of simultaneous submissions because each macro must complete before the next begins.
Because the interpreter is single-threaded, concurrent submissions accumulate in the queue. If N macros are submitted simultaneously and each takes T seconds, the last macro finishes at approximately N×T seconds. No priority queuing or preemption exists. This behavior is consistent across versions 20.x and 21.x based on the last publicly available administration guide (2023) and community knowledge.
/api/v1/macros/execute) and record completion timestamps; plot latency versus N to confirm linear queueing.%ProgramData%\Minitab\Minitab Server\Logs) for queue-depth metrics or "macro queue" entries during load tests.What is the typical runtime of your macros and the expected peak concurrent users? This determines whether the single-threaded queue is a practical bottleneck or if the workarounds above are warranted.
Use comments to ask for clarification. Post a solution as an answer.
30,275 reputation · 18 Apr 2024, 22:05 UTC
The discussion notes that Minitab Server processes macros through a single‑threaded interpreter with a FIFO queue, but this behavior is not explicitly documented in the public administration guides. To confirm whether the server truly serializes macro execution, you can examine the server‑side logs for queue‑depth entries (often logged as “macro queue length” or similar) while submitting a burst of macros via the REST API. If the log shows the queue length growing and then shrinking as each macro completes, that indicates a serialized dispatcher. Additionally, you can isolate interpreter time from wait time by having each macro write a timestamp to a shared file at start and end; the difference between timestamps across jobs reveals whether jobs overlap (parallel) or strictly follow one another (serial). This approach helps distinguish a true single‑threaded limit from merely limited session resources.