How much load on the server would cause the comparison to be queued up?
In general, a comparison is started without queuing if the available memory is at least around 15% of the maximum of the process and if there is a free executor thread. An additional constraint is the projected heap requirement for the documents to be compared. So for larger documents more free memory is required. These measures are taken to avoid an out-of-memory situation which could lead to an unstable state of the application.
So, it’s not only a matter of the (Unix-)load value but takes the current free memory and the expected memory requirement into account as well.
The current memory usage and the available memory can be seen in the ‘Dignostics’ module. The details for each job can be found in the ‘Jobs’ view of the ‘Statistics’ module. This module is inactive by default ans has to be activated in the configuration (or in the Plugin-Store as of version 21.10).
What are the options to remediate intermittent queuing issue? Would increasing the sizing would help or can you suggest any options/best practices to mitigate this?
The queuing can only be reduced but not completely avoided. One option is to increase the number of available job executors in the server configuration: https://docs.inetsoftware.de/pdfc/help/performance-execution/p/job-execution
In addition, please consider to grant more CPU cores and memory to the container. In general, we recommend 2 CPU cores and about 1GB of heap memory per parallel comparison. But this recommendation highly depends on the documents to compare. Large documents with images require a lot more performance and memory than simple texts.
To find out how many jobs the current server configuration can handle, you can check the ‘Jobs’ panel of the ‘Diagnostics’ module while a the comparisons are running: https://docs.inetsoftware.de/pdfc/help/stat_jobs/p/jobs