1.7 Thread Execution and Licenses

Aqua Data Server is licensed on a per-thread basis. One license key allows for the running of one Instance of the Software Product with a predetermined maximum number of simultaneously executable Threads. The Aqua Data Server licensing mechanism limits the number of threads users may execute in a given moment of time. The limitation applies to the total number of threads being run by all users currently working with Aqua Data Server.

Every Script in Aqua Data Server runs in a single “Execution Thread”, and most other user actions in Aqua Data Server require an Execution Thread to run. Such actions include clicking on a tab or link or running a query – in general this means every action that results in sending a request to the server from the browser of the user and receiving a server response. Unlike scripts, GUI actions allocate threads for a significantly shorter time.

The execution thread allocation and release process may cause delays with execution scripts and GUI actions within Aqua Data Server. Understanding the execution thread mechanism will help you optimize server performance and make decisions regarding the procurement of additional thread licenses.

An evaluation license of Aqua Data Server allows for a maximum of 3 threads to be launched simultaneously. Users can either launch their scripts manually from the Aqua Data Server project workspace or schedule them for automated launch using the scheduler. Both ways of launching the scripts will result in the launch and execution sequence shown on the diagram below.

The following example and diagram show the user scripts launch order and timing if a maximum of 3 threads are allowed by the license. In this scenario two users (A and B) are working with Aqua Data Server. They’ve created four AquaScripts for their projects and are executing them. The scripts may be reports, export-import operations or any other data processing operations programmed by the users. The scripts require a certain amount of time to perform the intended operation. In this example Script 1 and Script 2 will take 4 seconds from start to finish to complete their operations. Scripts 3 and 4 will take 6 seconds

1. User A launches Script 1 at 0 sec. Launching of this script initiates Thread 1.
2. One second later User A launches Script 2 (moment 1 sec). Thread 2 is initiated.
3. At 1.5 sec User B launches Script 3 which initiates Thread 3. All scripts launched start their execution at the moment the user launches (or schedules) them. At that moment all three threads are initiated (moment 1.5 sec) and all execution threads are in use. Aqua Data Server will not be able to run any additional script until one of the previously launched scripts completes its execution. Between 1.5 sec and 4 sec all available threads are in use.
4. User B launches Script 4 at 2 sec. Since all threads are in use, the script won’t execute and will be put on hold by the server until one of the execution threads is released. At 4 sec Script 4 is launched since Script 1 has completed its execution and released the thread.

In this example the launch (or scheduled) time for the Script 4 was different from the actual Start time. The script was put on hold by the server for the period of 2 seconds as it awaited the release of an execution thread.  For simplicity this example does not include short time thread allocations by GUI actions of users. In reality, if all actions are taken into the account, the diagram would look more complex, however the principle remains the same – if all thread licenses are used, the server will put all consecutive actions on hold (in the order they are scheduled or launched from the GUI) and will start them once an execution thread becomes available.

Timeout Settings for GUI and Scheduler

Aqua Data Server allows timeouts for the scripts or other actions put “on hold” due to the absence of the thread license. If the “on hold” time exceeds the timeout threshold the scheduled script will be removed from the schedule and will not start (even if the license becomes available).  Information about jobs aborted due to the timeout will be logged in the job's history stating that maximum execution threads exceeded.

The Scheduler timeout can be set at the Admin > System Settings > License > “Maximum wait time for scheduler to acquire license” dialog.

The same principle is valid for the GUI actions put “on hold”. After the time out has expired the action will be aborted and the notification message “Maximum Licenses Exceeded” will be displayed to the user.

GUI timeout can be set at the Admin > System Settings > License > "Maximum wait time for GUI to acquire license" dialog.

General Optimization Guidelines

The start time for scripts scheduled to run on Aqua Data Server depends on the sequence, timing, frequency, performance of other scripts and number of purchased thread licenses.

For a given number of licenses certain optimization steps may be considered for better leveling load on the server and minimizing “on-hold” time. General recommendations include the following:

• Avoid creating scripts with infinite loops. Once launched an infinite loop script would acquire an execution thread indefinitely. If you need a periodic action performed by the script, you should create a one-time operation within the script and schedule this script for a recurring execution by the Aqua Data Server Scheduler. This will allow the script to run only when it is necessary and release the execution thread upon completion. The downside of this approach is that there is no guarantee for timely execution of the script because it may be put on hold due to other scripts being execution.
   
• Optimize script performance with the objective of reducing execution time. This will allow the execution thread to be used for a shorter period of time.
   
• Schedule non-critical or long executing scripts at non-peak usage hours. Shorter scripts will likely be better to schedule at peak usage hours. With this approach users will experience more frequent but less prolonged delays and they will be able to start their scripts more quickly.
   
• Consider periodic server hardware upgrades. Faster hardware reduces the time of script execution.