Container Scaling
How many containers does an application with TX Text Control .NET Server need, and which of its parts runs out of resources first? The answer differs for its three workloads: the connections of the Document Editor, the editing sessions in the backend and the processing of documents. Each needs a different resource and scales on a different measure, so a deployment that separates them can give each what it needs. How the load balancer keeps an editor on its container is covered by Scaling Containers in the Deployment Guide.
Three Workloads, Three Measures
For many concurrent users, Text Control recommends three services that scale separately:
| Workload | What it does | What it needs | How it scales |
|---|---|---|---|
| Application instances with the WebSocket middleware | Accept the connections of the editors and serve the web application | Sticky sessions for the editors; Text Control recommends no heavy document processing here | Behind a load balancer with sticky sessions |
The Document Editor backend TXTextControl.Web.Server.Core | Synchronizes the documents and lays out the pages of every open editor | 50 to 150 MB of memory per editing session, and eight or more CPU cores | With the number of concurrent editing sessions |
| A document processing application | Creates PDF documents, merges batches and converts documents with ServerTextControl and MailMerge | CPU and memory, depending on the size and complexity of the documents | Automatically, on CPU usage or the length of its job queue |
The diagram of the blog article Scaling TX Text Control Document Editor Applications shows how the three connect: the browser talks to the application over WebSocket, and the application forwards document synchronization to the backend instances and document processing to the processing application through Web API calls:
Text Control describes editing as predictable, memory-bound work and document processing as unpredictable, CPU-heavy work. In one instance, a peak of processing can slow down the editors and block their WebSocket connections; in separate services, it doesn't reach them. The layout works with virtual machines, containers and Kubernetes clusters, on Azure, on AWS and on your own servers. The blog article Scaling TX Text Control Document Editor Applications describes it, and Scaling Beyond One Instance summarizes it.
Smaller deployments run all three in one container, as Multiple Processes in the Deployment Guide shows. The same numbers then add up in that container.
Size the Document Editor Backend
Every connected editor has a worker process of its own in the backend, which holds the document of the session in memory. Text Control's sizing guidance is 50 to 150 MB per editing session; how much depends on the spell checking dictionaries that are loaded. Multiply it by the number of editors that are open at the same time:
| Concurrent editing sessions | Memory for the sessions |
|---|---|
| 10 | 0.5 to 1.5 GB |
| 50 | 2.5 to 7.5 GB |
| 100 | 5 to 15 GB |
Add the memory that the application itself needs. Text Control gives no figure for it, so measure it without open editors. For the backend, Text Control recommends eight or more CPU cores.
- Containers and cloud services. Size the memory of a container, task or instance for the sessions it is to hold, as the pages for AWS and Google Cloud do for AWS Fargate and Cloud Run.
- Connections aren't sessions. An editor opens two WebSocket connections while it initializes. Platforms that limit concurrent connections per instance, such as Cloud Run, reach their limit before the number of editors suggests.
- Count the sessions. For each editor that connects, the backend logs "Starting web editor worker process with connection ID" followed by the ID, and each session is a worker process that the operating system shows with its memory. Memory Usage describes what else takes memory.
Scale the Processing Service
A document processing service needs no sticky sessions: every request can go to any instance, as long as your code keeps no state in the memory of an instance. It can therefore scale automatically on CPU usage or on the length of the queue in which it collects jobs. Text Control publishes no maximum number of documents that one instance creates in parallel, so determine it with load tests of your own templates and data, and limit the parallel work of each instance to it. For batches of hundreds or thousands of documents, Text Control recommends several processes instead of several threads in one process, which can wait for each other at TX Text Control's critical sections, as Multiple Processes describes.
Faster processing needs fewer instances. Text Control projects from its benchmarks that 1,000 documents of 1,588 pages each, due within four hours, need about 12 workers with the Classic engine and about 2 with the Core engine. The blog article From Milliseconds to Cloud Costs: The Real Impact of Faster Document Processing in C# .NET points out that this is a projection, not a measured deployment: it assumes that workers scale linearly and leaves out startup times, storage and the network.
Scale In Without Losing Work
A container that a platform removes takes its editing sessions with it: the backend stops with the application, and the worker processes end with their documents. Changes that weren't saved are lost, so save documents regularly, as When Containers Stop or Are Replaced describes.
Licenses Grow With the Instances
Each running instance of your application, such as a container that a platform starts under load, needs its own runtime license. For deployments whose number of instances changes automatically, Text Control offers an unlimited runtime license. Cloud and Container Deployments and OEM / Unlimited Runtime describe the options.
Next Steps
- Scaling Containers: the load balancer, sticky sessions and the layouts of backend containers.
- Memory Usage: what documents, instances and editing sessions need in memory.
- Multiple Processes: process large batches in parallel worker processes.
- Kubernetes: run and scale the containers in a cluster.