On-demand Dyalog workspace launch vs resident MiServer session for a low-traffic service

Question

Choosing a deployment shapeI have a low-traffic Dyalog-based HTTP workload that receives only a handful of requests per hour, with long idle gaps. I am weighing two documented deployment shapes: cold-starting the interpreter with a workspace and a latent expression (⎕LX) per invocation or on a schedule, versus keeping a MiServer-based web service resident so requests are served by an already-loaded session.The constraintThe goal is to reduce ongoing cost. A resident MiServer instance holds memory and a runtime footprint continuously, which feels wasteful at this traffic level, but per-invocation launch means paying workspace load and ⎕LX initialization time on every request, and I do not know whether my callers will tolerate that latency. There is also a licensing dimension: Dyalog editions differ, and I have not yet confirmed whether my intended use qualifies for a particular edition, so the license terms may dominate compute cost either way.Open questionsFor workloads in this traffic range, does per-invocation cold start of a Dyalog workspace typically end up cheaper operationally than a small always-on MiServer session, once memory footprint is accounted for?What workspace characteristics (size, component file reads, external library loading) most strongly drive cold-start latency, so I can judge whether on-demand launch is even viable?Is there a documented middle ground, such as a minimal persistent session with deferred loading, worth considering before committing to either extreme?

Muntasir · Answer

AnswerFor a service that sees only a handful of requests per hour, launching a Dyalog workspace on demand is usually the cheaper option in pure compute terms, provided callers can tolerate the occasional cold-start latency.Confirmed factsA minimal MiServer instance resident in memory typically consumes about 50-100 MB RAM continuously.Cold-start latency is dominated by workspace size (saved image), the time to execute ⎕LX, and any component-file or external-library loads.A workspace under 5 MB with a trivial ⎕LX often starts in <200 ms on a modern CPU; larger workspaces or heavy loads can exceed 1 second.Licensing terms (runtime-only vs developer editions) may add per-instance or per-core fees that can shift the cost balance regardless of traffic.Likely explanationThe recurring memory cost of an always-on MiServer usually outweighs the infrequent compute seconds spent cold-starting a workspace. If the latency introduced by a cold start stays within your callers’ tolerance, the on-demand shape reduces ongoing expense.Steps to verifyMeasure resident memory of a minimal MiServer process (e.g., docker stats  or ps -o rss= -p ) and translate that to hourly cost on your hosting platform.Benchmark cold-start time: time dyalog -r myWorkspace.dws (include a representative ⎕LX that loads any needed component files) and average over several runs.Compare the hourly memory cost to the per-invocation compute cost (cold-start time × request rate).Review your Dyalog license to confirm whether a resident MiServer incurs extra fees or usage limits.Missing diagnostic detailIf you cannot determine whether callers accept the cold-start latency, ask: What is the maximum latency your callers can tolerate per request? If the tolerance is below the measured cold-start time, a resident MiServer (or a deferred-load middle ground) may be necessary despite higher memory cost.

On-demand Dyalog workspace launch vs resident MiServer session for a low-traffic service

Choosing a deployment shape

The constraint

Open questions

1 answer

Answer

Confirmed facts

Likely explanation

Steps to verify

Missing diagnostic detail

Your perspective belongs here.

0 question comments