Session Processing Overview

The Mi-Forms Server is setup to give priority to responding to incoming requests over processing sessions waiting for workflow and export. This ensures that users uploading sessions have quick response times. However, during busy time periods this can lead to the backlog of unprocessed sessions. The Server's handling of this session backlog is configurable by an administrator.

When a session is uploaded to the Server, the basic life cycle is as follows:

Device Upload -> _Incoming Queue -> _Processing Queue -> _Finished Queue or other workflow queue

Immediately on upload the Server will accept the form session into the _Incoming queue. The Client is notified that the Server has accepted the session and may continue its operation without further waiting.

The Server then makes use of separate threads called "Session Processing Threads" to actually process the form data. Each of these threads wake up every 1 second and look in the _Incoming queue to see if there are any sessions in need of processing. If so, the thread will move the session to the _Processing queue, perform workflow, image generation, and other tasks, and as needed retire the form to the _Finished queue. Upon completion, the thread will then look for another available session in the _Incoming queue.

In a situation where many users upload forms at once, it's possible that many sessions will be in the _Incoming queue when each thread attempts to find a session for processing. The sessions are acted on in a first come, first serve basis. The number of threads that are configured to run will directly impact how fast the _Incoming queue backlog is processed.

Configuring Session Processing Threads

Depending on the resources available to your Server, you may wish to directly configure the number of session processing threads that are running. By default, each customer configured on the server is setup to have 2 session processing threads.

The number of session processing threads created is specified in the Mi-Forms Server's web.config file. In a normal installation this file is located in c:\inetpub\wwwroot\mfs but may be in a different location depending on your server's configuration. Please be sure to backup this file before making changes.

Open the web.config file in a text editor and locate text that looks similar to this:

<!-- Session processing engine -->
<add key="sessionprocessor.threadcount" value="2"/>

The highlighted number above shows the number of threads that will be created per customer configured on the server. It's important to note that this is a per customer number. For instance, if your server has 10 customers configured and this value is set to 2, then 20 total threads will be running, but only 2 will be active per customer to handle forms backlog. 

Determining a good number of threads to use

There is very little overhead in configuring many session processing threads when there is no backlog of forms as each will wake up, discover no work to be done, and then go back to sleep. However, when there is a backlog of forms, it's important to balance this number versus available  server resources. In general, processing form sessions scales well with CPU and memory availability. However, as there is also I/O involved in processing sessions, it may be beneficial to configure this number with that in mind. Ideally, the total number of active session processing threads (that is, threads actually processing forms at a given time) should not exceed the number of available CPU cores on the system by more than 1 or 2. This should ensure that the threads can be serviced without large amounts of context switching.