Bug #78531 Make NDB scheduler adaptable for more throughput or for better responsiveness
Submitted: 23 Sep 2015 14:16 Modified: 6 Jan 2016 1:38
Reporter: Mikael Ronström Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Cluster: Cluster (NDB) storage engine Severity:S3 (Non-critical)
Version:7.4.7 OS:Any
Assigned to: CPU Architecture:Any

[23 Sep 2015 14:16] Mikael Ronström 
Description:
The NDB scheduler is hard-coded for one behaviour. This behaviour doesn't necessarily reflect all needs.
One customer might want as much responsiveness as possible and another one might require more throughput
at the expense of responsiveness.

How to repeat:
Run various benchmarks with various configs.

Suggested fix:
Introduce new config parameter SchedResponsiveness with high values 6-10 meaning that we optimise on
response times more and more. Low values 1-4 means we optimise on throughput, the lower the more
throughput oriented we become.
[6 Jan 2016 1:39] Jon Stephens 
Documented feature addition in the NDB 7.4.9 changelog as follows:

    Previously, the NDB scheduler always optimized for speed against
    throughput in a predetermined (hardcoded) manner; this balance
    can now be controlled using the SchedulerResponsiveness data
    node configuration parameter. This parameter accepts an integer
    in the range of 0-10 inclusive, with 5 as the default. Lower
    values provide better response times relative to throughput.
    Higher values provide increased throughput, but impose longer
    response times.

Also noted the new parameter in the MySQL Cluster configuration documentation.

Closed.