There are several possibilities to optimize the speed of JobRouter via specific settings. This is recommended especially for productive systems, to enhance user experience. When JobRouter is newly installed, usually the configuration is optimized, though it may occur - after regular JobRouter updates on older systems - that specific optimized settings are not performed automatically but have to be adapted manually. Both methods will lead to a significant improvement of the speed.
In this chapter those settings are compiled, which are recommended for a new installation. Their utilization often leads to a remarkable improvement in old systems.
Please note: The following settings may necessitate the restart or new installation of the software or can have a deep impact on the availability and/or safety of the system. So please be careful and complete a backup up-front.
Perform speed measurement
Before you start with the activities concerning the improvement of the JobRouter speed, get an overview of the period of time JobRouter needs to process a call. Hereby, it is important to make an up-front measurement and a measurement after the change, based on the same server load. Server load variations can lead to extreme deviations, which rule out clear statements on the performance change of a specific activity.
The following constant in the config.php on the bottom right indicates the time in JobRouter, which is needed in PHP for the processing of a JobRouter page call. In case of eventual load variations it can only be seen as a rough guide value and is not suitable for exact measurements.
define('CONST_SHOW_TOTAL_TIME', true);
Web server and PHP settings
Is FastCGI optimally configured in IIS?
The default settings of FastCGI in IIS are not optimal for productive systems. To check or adapt the settings, please proceed as follows:
•Start the IIS manager. Here click on the server node first. Then double-click on FastCGI settings
•A list of all registered FastCGI applications is displayed
•Select the PHP version active for JobRouter
•Now click on the right side on Edit
The following settings should be made:
•"MaxRequests" instance – 10000
•Max. number of instances – 50 (at least, depending on the load and the available working memory, a higher value may influence the speed positively)
•Activity timeout – 600 seconds (at least, but not less than the value stored by PHP in the setting max_execution_time in the php.ini configuration)
•Requirements timeout – 300 seconds (at least)
•Idle timeout – 900 seconds (at least)
If the value of one of the settings is lower as above, it is recommended to fix the value. Then go to the environment variable line and click on the button on the right next to Listing/Collection. Check if the following environment variables have been added:
•Name: PHPRC, value: Path to the PHP installation directory
•Name: PHP_FCGI_MAX_REQUESTS, value: 10000 (identical with the setting "MaxRequests" instance)
Is the PHP opcache activated and set correctly?
The opcache stores PHP files in precompiled, optimized condition and provides an immense acceleration of all PHP calls. In the best case the configuration of the opcache is made in a way that keeps the cache completely in the memory, this reduces the number of slow file accesses. The following settings ensure the activation and the optimal setting of the opcache for JobRouter: (configuration file php.ini):
; load opcache extension
zend_extension="C:\Program Files\PHP 7.4\ext\php_opcache.dll"
;...
[opcache]
opcache.enable=1
opcache.enable_cli=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=32
opcache.max_accelerated_files=100000
;opcache.validate_timestamps=0; When disabled, you must restart the webserver for changes to the filesystem to take effect.
opcache.revalidate_freq=5
opcache.enable_file_override=1
opcache.dups_fix=1
opcache.error_log="C:\Program Files\PHP 7.4\logs\opcache.log"
;opcache.log_verbosity_level=2
opcache.mmap_base=0x20000000
opcache.file_cache="C:\Program Files\PHP 7.4\tmp\opcache"
;opcache.file_cache_only=1
opcache.file_cache_fallback=1
In any case, check before saving and newly starting the web server, if the paths for Log files and opcache are specified correctly and PHP has the write rights for these directories.
Is the Xdebug extension deactivated?
The Xdebug extension is used for the detection of problems in program codes. However, it can lead to a much slower performance of PHP in productive systems, as additional instructions have to be carried out for each call. So make sure that the extension is separated and so disabled by a semicolon:
;zend_extension="C:\Program Files\PHP 7.4\ext\php_xdebug.dll"
Please note: If you deactivate the Xdebug extension, please also delete all files and subfolders from the tmp/opcache folder. You will find the path to this folder in php.ini at the option opcache.file_cache.
Example:
opcache.file_cache="C:\Program Files\PHP 7.4\tmp\opcache"
JobRouter and service configuration
Besides the infrastructure a configuration change in JobRouter can also contribute to a speed increase. Of course, this also includes the service configuration.
Is the JobRouter cache on a fast drive?
Please note: If you use a caching server (such as Redis) or a JobRouter version > 4.1.6, this problem should not be relevant for you.
JobRouter is using a file cache to reduce the number of required database requests. The path to the file cache can be adapted in the path configuration. This path should be on a fast drive to optimize the cache access.
It becomes particularly problematic to outsource this directory to a network drive (e.g. \\sharing-server\jobrouter\cache). Even if the network drive has a very fast link, the file access via the network will always be slower than the local directory access. Unfortunately, due to place and maintenance reasons, it is not always possible to outsource the cache to network drives in productive systems.
This problem could be solved with the current JobRouter versions > 4.1.6 by always saving the general JobRouter cache, which is needed for every JobRouter call, in a local directory, regardless of the cache path configuration. Though, in any case, it is appropriate to ensure that ideally the config.php does not contain the constant CONST_FIXED_CACHE_PATH and by no means is not configured for a network.
Is the dialog cache activated?
JobRouter has an additional dialog cache. This dialog cache should be active in productive systems. So please ensure, that, ideally, the config.php does not contain the constant CONST_CACHE_DIALOGS and by no means is set on false in the configuration.
Is the Log level set correctly in the config.php?
Log files are usually written when errors occur. To detect errors, the Log level can be modified in order to display more detailed and numerous messages in the log file. Please ensure that the following constants are not entered (or commented out) in the config.php:
CONST_ERROR_REPORTING, CONST_LOG_LEVEL_FILE, CONST_DEBUG
Is the Log level for services set correctly?
The Log level can also be set for JobRouter services. In productive system this log level should be set via the JobRouter service configuration on "Warn".
Is there a need for counters for inboxes?
A common problem in extremely largely set systems with many users is that the so called counters of the inboxes are actualized with every JobRouter call. Thereby, complex database requests are created. Though the small number next to the inbox is useful, it increases the server load tremendously. So if you can waive this information in connection with an optimization, use the following constant in the config.php:
define('CONST_SKIP_COUNTER_UPDATE_ON_RELOAD', true);
Do slow database statements or even deadlocks occur?
A slow database is the most common reason for slow performance speed. Unfortunately, here the optimization is so complex that it has to be performed strongly individualized and there is no general way to do it. But it can easily be determined if there are problems with the database.
Therefore, all JobRouter requests proceeding the runtime of 0,5 seconds are saved in the log file output/log/db_<Datum>.log. If you find according requests in the Log file occasionally, this is no cause for concern. According to the utilization and complexity of the requests, it is possible that now and then such requests occur. But if this problem occurs cumulatively or if even leads to deadlocks, this indicates a problem with the database and a detailed check is reasonable.
For Oracle systems with weak performance this additional constant in the config.php can lead to a performance improvement:
define('CONST_DB_NO_QUERY_TRANSFORMATION', true);
Further influencing factors
Are you using an old browser?
The utilization of an old browser (such as Internet Explorer 11) can especially influence the dialog display speed negatively. The recent developments in modern browsers lead to a much faster handling of web applications with high script rate.
Is the antivirus or another protection software active?
Performance problems or function limitations often occur, when the antivirus or another protection software is active, monitoring and so slowing down the file access and the network traffic. The easiest way to check if an installed software is negatively influencing the JobRouter speed is to disabled it temporarily and test the impact on JobRouter.
If a difference can be detected, it is possible to define frequent exceptions in the protection software for programs and directories - here to name PHP as application, the basic directory of JobRouter codes (mostly in C:\inetpub\wwwroot), as well as all outsourced or utilized JobRouter directories.
Is the virtual network adapter active?
Often performance problems on a virtual network adapter (VMWare, VirtualBox, Hyper-V, etc.) can be traced back to the JobRouter server. The easiest way for a check is the disablement of all not absolutely essential network adapters. In most cases a restart of the web server is not necessary.
Here you can also set a constant in config.php that determines which of the available IP addresses should be used for the license check:
define('CONST_LICENSE_IP', '192.168.47.11');
This avoids the use of an IP address with a very slow hostname resolving.
