As discussed in previous sections, the QR provides the
checkQueue parameter to allow applications define how they would like to clear request queues. The default implementation provided uses a first-in, first-out (FIFO) approach. A table of queued requests is the input to this analytic. As the number of requests in the queue grows, the lookup of data for each can become a latency bottleneck. To improve this, a
useFIFO parameter has been added to the QR template. When enabled, the QR still implements FIFO but in a more performant way and bypasses
The new FIFO mode will not be enabled if the QR has a custom analytic specified for the
checkQueue hook. To enable FIFO, ensure the analytic is set to
dxQRCheckQueue and set
The QR logging has been made configurable. By default it uses the Platform version but can be configured to use a slimmer mode. This mode shortens the message text and simply pushes to
This is set using the
platform Platform logging APIs (default) slim new slim logging APIs none disable QR-specific logging
For the 4.5.0 release, QR performance was improved in comparison to previous releases. The focus of the improvements is within the QR process itself, receiving and dispatching requests. This section details the improvements under three scenarios:
- Immediate – client sends requests for available database, immediately dispatched
- Queued – database unavailable, requests get queued
- Dequeued – queue of requests, requests dispatched when DB becomes available.
These scenarios are compared between 4.5.0 and 4.4.0.
4.5.0 release is running in FIFO mode.
Base performance improvement between the two versions is shown in the table below. During the investigations, performance was shown to be linked to the number of processed requests or the size of the request queue. Two sets of tests were run to examine performance under different conditions; small and large numbers of queued/processed requests.
The results indicate that performance degradation was a significant issue in the 4.4.0 QR. Each of the test scenarios was also investigated on small and large numbers of processed and queued requests. In the immediate scenario, performance is linked to the number of requests. For the queue and dequeue cases, it is linked to the queue size. The table indicates the degradation for each version with the corresponding number of requests.
In 4.5.0 FIFO mode, the QR shows negligible performance degradation as the number of requests grows.
Comparing the performance of FIFO mode against a simple custom dequeue analytic for the Dequeued scenario. The test is the same as before with a small and large number of queued requests. Using a queue size of 10,000 requests for the large case and less than 100 for the small case, the custom dequeue analytic performs 98% worse.
The other two scenarios are unaffected by this mode.
- Slim logging mode is 5-10% faster than the platform mode
- No QR logging is 20-30% faster than platform