In Indicium Universal, executing seems to contain 2 steps;
A staging step, in which a task's default and layout procedures are called, and the context of the parent subject is checked to see whether the user is authorized to execute the task.
The URL for this task looks as such:
The response of this request contains a
Location header, in which a URL to the staged task is supplied with a GUID.
Step 2, which is the actual execution of the task, is much simpler; we simply make a POST request to
http:///indicium/(iam/sf)//staged_execute_task()/commit, which will execute the task on the resource specified when staging the task (
idtwo 2 and
idthree 3) and returns a response.
We implemented this in our external API based on what happens in the Universal GUI, where we had previously implemented Indicium Basic. However, we noticed a pretty severe downgrade in performance when using Universal as explained above. We ran a simple performance comparison test between Universal and Legacy, in which we repeatedly executed the same two tasks for 10 minutes each.
Below are the results of these tests;
Please note when reading:
- In the Universal results, the execution of both steps is counted as one request, as in Legacy task execution simply requires a single POST call be made to the task itself.
- In Basic, we did not include calls to defaults and layouts or contexts.
As can be seen in the results, Indicium Basic executed just over twice as many requests as Universal over the same timespan, with an average response time roughly a third of Universal's average response time. Of course, we are talking microseconds and to the human eye it will be barely noticeable, however in technical terms this is quite significant.
This difference in performance can, in part, be explained by the simple fact Indicium Universal does much more background work than Indicium Basic. That background work is, apart from soon to be discontinued support for Indicium Basic, our main reason for this switch. However, this performance downgrade is quite severe, moreso than we feel it should be.
As said above, we implemented these steps based on how the Universal GUI handles task execution. When executing a task in the Universal GUI whilst having an open network inspector, these same requests can be seen in the inspector, and so we implemented this method as such.
However, we are now wondering whether there is, or whether there should be, a more efficient way of executing these tasks. One that does the same as these 2 steps we have now implemented, but in a single request for example. Having to incur and wait for 2 separate HTTP requests to finish only adds to the “expected” performance cost in Universal due to all the background jobs.
Should you have any questions, do please ask in a comment!
Thank you in advance!
Best answer by Vincent DoppenbergView original