While benchmarking some tweaks to Hasura we noticed some strange behavior. We were measuring latencies for a simple GraphQL request being served by Hasura. Surprisingly Hasura was performing better when there was more load on the system than otherwise.
At 100 requests per second the processor load was low enough that the processor going to sleep was negatively impacting the latency measurements. However, when a browser was open on the same machine, latency measurements improved!
The explanation for this is quite intriguing and is documented in detail in this post by Brandon. This blogpost explains that post from a layman’s perspective.
Background
Modern Intel processors have extremely sophisticated power management that modifies the clock frequency and powers up and down subsystems dynamically and constantly. This can happen several times a second.
p-states and c-states
Power management happens both when the processor is idle and otherwise. Idle states of a processor are called C-states and are denoted as C0, C1, C2... C0 is the operating state whereas C1, C2, C3.. are states where some or more of the subsystems are shutdown. Generally the higher the C-state the lower the power consumption but also the longer it takes for the processor to move back to the operating state C0.
We can look at the idle states available on my laptop using the cpupower command:
$ cpupower idle-info
CPUidle driver: intel_idle
CPUidle governor: menu
analyzing CPU 0:
Number of idle states: 9
Available idle states: POLL C1 C1E C3 C6 C7s C8 C9 C10
POLL:
Flags/Description: CPUIDLE CORE POLL IDLE
Latency: 0
Usage: 5845
Duration: 3482887
C1:
Flags/Description: MWAIT 0x00
Latency: 2
Usage: 155904
Duration: 40263250
C1E:
Flags/Description: MWAIT 0x01
Latency: 10
Usage: 505874
Duration: 163384145
C3:
Flags/Description: MWAIT 0x10
Latency: 70
Usage: 405130
Duration: 115592556
C6:
Flags/Description: MWAIT 0x20
Latency: 85
Usage: 2407019
Duration: 1503034108
C7s:
Flags/Description: MWAIT 0x33
Latency: 124
Usage: 657
Duration: 674710
C8:
Flags/Description: MWAIT 0x40
Latency: 200
Usage: 1694254
Duration: 2067037470
C9:
Flags/Description: MWAIT 0x50
Latency: 480
Usage: 38
Duration: 65699
C10:
Flags/Description: MWAIT 0x60
Latency: 890
Usage: 44032
Duration: 79069478
We can see that my processor has these idle states available: POLL, C1, C1E, C3, C6, C7s, C8, C9, C10. We can also see a Latency field that tells us the maximum time (in µs) the processor will take to go from that state to the operating C0 state. It is possible to enable/disable these states using the cpupower idle-set command.
Similarly when a processor is not idle it will be in one of several P-states denoted by P0, P1, P2, P3. The higher the p-state, the lower the voltage and operating frequency of the processor. This means CPU bound programs will in general execute faster in a lower P-state than a higher p-state. We cannot explicitly set the processor to a particular state. However we can set a CPUFreq governor using the cpupower frequency-set -g <governor> command.
On my laptop I can see the available governors with:
$ cpupower frequency-info
analyzing CPU 0:
driver: intel_pstate
CPUs which run at the same hardware frequency: 0
CPUs which need to have their frequency coordinated by software: 0
maximum transition latency: Cannot determine or is not supported.
hardware limits: 400 MHz - 4.00 GHz
available cpufreq governors: performance powersave
current policy: frequency should be within 400 MHz and 4.00 GHz.
The governor "powersave" may decide which speed to use
within this range.
current CPU frequency: Unable to call hardware
current CPU frequency: 1.60 GHz (asserted by call to kernel)
boost state support:
Supported: yes
Active: yes
We can see that I can set the governor to performance or powersave and the current governor is powersave.
This article explains the various P-states and C-states that intel processors implement in greater detail.
We can also measure the time spent by the processor in various states using the turbostat command:
$ sudo turbostat --quiet sleep 5
5.004098 sec
Core CPU Avg_MHz Busy% Bzy_MHz TSC_MHz IRQ SMI C1 C1E C3 C6 C7s C8 C9 C10 C1% C1E% C3% C6% C7s% C8% C9% C10% CPU%c1 CPU%c3 CPU%c6 CPU%c7 CoreTmp PkgTmp GFX%rc6 GFXMHz Totl%C0 Any%C0 GFX%C0 CPUGFX% Pkg%pc2 Pkg%pc3 Pkg%pc6 Pkg%pc7 Pkg%pc8 Pkg%pc9 Pk%pc10 PkgWatt CorWatt GFXWatt RAMWatt PKG_% RAM_%
- - 6 0.35 1640 1991 2009 0 1 54 11 78 0 1555 0 523 0.00 0.01 0.00 0.18 0.00 27.94 0.00 71.50 0.95 0.00 0.30 98.39 54 55 99.96 300 2.76 1.83 0.00 0.00 20.55 0.12 0.09 0.15 75.31 0.00 0.00 0.76 0.09 0.00 0.32 0.00 0.00
0 0 12 0.77 1625 1991 730 0 0 2 5 48 0 603 0 90 0.00 0.00 0.01 0.98 0.00 47.68 0.00 50.57 1.25 0.00 0.90 97.07 54 55 99.96 300 2.76 1.83 0.00 0.00 20.56 0.12 0.09 0.15 75.31 0.00 0.00 0.76 0.09 0.00 0.32 0.00 0.00
0 4 4 0.25 1650 1991 154 0 0 0 0 4 0 125 0 70 0.00 0.00 0.00 0.07 0.00 22.48 0.00 77.17 1.77
1 1 2 0.15 1689 1991 95 0 0 8 0 3 0 66 0 32 0.00 0.01 0.00 0.05 0.00 9.76 0.00 90.01 0.86 0.00 0.08 98.91 54
1 5 6 0.35 1626 1991 222 0 0 0 0 4 0 129 0 115 0.00 0.00 0.00 0.06 0.00 18.13 0.00 81.44 0.67
2 2 5 0.31 1672 1991 187 0 0 1 0 6 0 163 0 53 0.00 0.00 0.00 0.10 0.00 39.79 0.00 59.78 1.02 0.01 0.13 98.53 54
2 6 8 0.50 1623 1991 299 0 0 1 6 5 0 246 0 61 0.00 0.00 0.01 0.08 0.00 46.01 0.00 53.39 0.84
3 3 4 0.27 1642 1991 180 0 0 5 0 5 0 139 0 43 0.00 0.01 0.00 0.07 0.00 29.59 0.00 70.05 0.58 0.00 0.10 99.06 54
3 7 3 0.19 1664 1992 142 0 1 37 0 3 0 84 0 59 0.00 0.05 0.00 0.05 0.00 10.11 0.00 89.58 0.66
In the above output we can see that the processor spends < 0.5% in C0 state (Busy%) because we are executing the sleep command and there is not much else happening on the machine. The bulk of the time is spent in C7 state (CPU%c7). This man page explains the various fields that turbostat will output.
Processor states while Hasura serves a GraphQL Request
How does all of this affect Hasura's performance you ask? Let us look at power management states of the machine while Hasura executes a simple GraphQL query. The below measurements were made on my laptop running Intel i7-8550U (1.8GHz turbo boost to 4GHz).
Both Hasura and Postgres were running on the same machine and a simple GraphQL query fetching about 5 rows was used. I've used wrk2 - launched using turbostat - to run a constant load of 100RPS.
Here's the output from the wrk2 command:
Running 1m test @ http://localhost:8181/v1/graphql
1 threads and 10 connections
Thread calibration: mean lat.: 2.489ms, rate sampling interval: 10ms
Thread Stats Avg Stdev Max +/- Stdev
Latency 2.49ms 521.70us 12.94ms 75.29%
Req/Sec 105.63 102.66 363.00 37.27%
Latency Distribution (HdrHistogram - Recorded Latency)
50.000% 2.52ms
75.000% 2.80ms
90.000% 3.03ms
99.000% 3.53ms
99.900% 5.90ms
99.990% 12.94ms
99.999% 12.94ms
100.000% 12.94ms
Here's the output from turbostat:
60.011521 secCoreCPUAvg\_MHzBusy%Bzy\_MHzTSC\_MHzIRQSMIC1C1EC3C6C7sC8C9C10C1%C1E%C3%C6%C7s%C8%C9%C10%CPU%c1CPU%c3CPU%c6CPU%c7CoreTmpPkgTmpGFX%rc6GFXMHzTotl%C0Any%C0GFX%C0CPUGFX%Pkg%pc2Pkg%pc3Pkg%pc6Pkg%pc7Pkg%pc8Pkg%pc9Pk%pc10PkgWattCorWattGFXWattRAMWattPKG\_%RAM\_%--503.0016691992700090261197115261101734710074176980.010.040.061.620.0249.450.0045.855.200.072.6389.103940100.0030024.3820.600.000.0025.921.420.420.1147.070.000.001.150.460.000.430.000.0000503.08162919928822032210185122589399220050.000.030.051.390.0351.970.0043.495.230.072.5689.073940100.0030024.3820.600.000.0025.921.420.420.1147.070.000.001.150.460.000.430.000.0004503.07161519929119049259216152359173021200.000.040.061.810.0348.680.0046.355.2411603.29180719928405020171191120108406020560.010.020.061.350.0049.630.0045.674.860.072.4289.363915452.75165319928734039385191138488161024980.000.070.051.640.0244.750.0050.755.4022523.15164419929181029269184143639256020080.000.070.061.700.0250.970.0044.075.190.072.4989.103926532.99175619927914025265183113828432022480.010.030.051.340.0149.800.0045.805.3533452.80161619928336025209150140168112026630.000.050.051.660.0244.790.0050.685.200.073.0688.883937462.851617199294980422032261709210068221000.010.030.062.120.0055.000.0239.955.14
We can see the processor was busy i.e in C-state 0 less than 3.5% of the time, while it spent about 90% of the time in the deep C-7 state, which is slow to wake and do useful work.
Essentially at 100 RPS Hasura takes so little of the processor time that the processor spends most of the time in deep sleep 🤓 That in turn increases the latency of requests because it takes time for the processor to wake up and serve the request.
Fine tuning processor states
"performance" p-state governor
How does using the performance governor improve the situation? Switching it to performance mode with...
$ sudo cpupower frequency-set -g performance
...reduces latency as the CPU is more ready to ramp up and do work when it comes:
wrk2 output:
Running 1m test @ http://localhost:8181/v1/graphql
1 threads and 10 connections
Thread calibration: mean lat.: 2.002ms, rate sampling interval: 10ms
Thread Stats Avg Stdev Max +/- Stdev
Latency 1.94ms 579.10us 9.26ms 68.44%
Req/Sec 105.33 100.88 333.00 43.93%
Latency Distribution (HdrHistogram - Recorded Latency)
50.000% 1.90ms
75.000% 2.34ms
90.000% 2.62ms
99.000% 3.21ms
99.900% 5.98ms
99.990% 9.27ms
99.999% 9.27ms
100.000% 9.27ms
We see better latencies at pretty much every percentile.
turbostat output:
60.006307 secCoreCPUAvg\_MHzBusy%Bzy\_MHzTSC\_MHzIRQSMIC1C1EC3C6C7sC8C9C10C1%C1E%C3%C6%C7s%C8%C9%C10%CPU%c1CPU%c3CPU%c6CPU%c7CoreTmpPkgTmpGFX%rc6GFXMHzTotl%C0Any%C0GFX%C0CPUGFX%Pkg%pc2Pkg%pc3Pkg%pc6Pkg%pc7Pkg%pc8Pkg%pc9Pk%pc10PkgWattCorWattGFXWattRAMWattPKG\_%RAM\_%--671.723930199267347022716481301913532725852171620.010.040.081.620.0150.840.0045.668.010.102.2387.954949100.0130013.7311.580.000.0019.861.410.350.0452.640.000.002.491.690.000.640.000.0000621.58392319929298034167175127739688019670.020.050.081.920.0154.270.0042.067.760.072.1788.424949100.0130013.7311.580.000.0019.861.410.350.0452.640.000.002.491.690.000.640.000.0004641.6439241992766203619614491728251021330.000.020.061.190.0147.090.0049.977.6911711.81393219928996026232196125349553120350.000.050.091.730.0153.370.0042.928.420.082.2587.444615681.74393319928754035224136113259662022930.020.040.061.590.0153.980.0042.548.4822701.78393719927611020200149106338247022600.000.020.081.530.0047.710.0048.857.350.081.7889.014726601.5439181992792002521013478028559119930.000.040.061.050.0151.940.0045.337.5833741.88393719928414025259164126239352020640.000.100.071.780.0249.070.0047.058.320.162.7286.914837691.763930199286920261602031451109273024170.000.030.172.160.0149.290.0046.568.45
Notice Bzy_MHz is now close to the maximum advertised frequency of 4GHz (with turboboost).
Prohibit idle states
We can keep the processor from entering deep sleep states with:
$ sudo cpupower idle-set -D2
This will disable any idle state with a latency >= 2µs which on my laptop is all idle states.
Here's the results from wrk2:
Running 1m test @ http://localhost:8181/v1/graphql
1 threads and 10 connections
Thread calibration: mean lat.: 0.995ms, rate sampling interval: 10ms
Thread Stats Avg Stdev Max +/- Stdev
Latency 1.13ms 353.31us 8.95ms 79.16%
Req/Sec 108.45 104.68 333.00 19.19%
Latency Distribution (HdrHistogram - Recorded Latency)
50.000% 1.20ms
75.000% 1.32ms
90.000% 1.41ms
99.000% 1.79ms
99.900% 4.33ms
99.990% 8.96ms
99.999% 8.96ms
100.000% 8.96ms
Again we can see an improvement at almost every percentile.
Turbostat output:
60.005077 secCoreCPUAvg\_MHzBusy%Bzy\_MHzTSC\_MHzIRQSMIC1C1EC3C6C7sC8C9C10C1%C1E%C3%C6%C7s%C8%C9%C10%CPU%c1CPU%c3CPU%c6CPU%c7CoreTmpPkgTmpGFX%rc6GFXMHzTotl%C0Any%C0GFX%C0CPUGFX%Pkg%pc2Pkg%pc3Pkg%pc6Pkg%pc7Pkg%pc8Pkg%pc9Pk%pc10PkgWattCorWattGFXWattRAMWattPKG\_%RAM\_%--368599.76369319926809116000000000.000.000.000.000.000.000.000.000.240.000.000.00858499.92300398.3899.590.000.000.000.000.000.000.000.000.0019.7318.800.000.350.000.0000368599.763693199292922000000000.000.000.000.000.000.000.000.000.240.000.000.00818499.92300398.3899.590.000.000.000.000.000.000.000.000.0019.7318.800.000.350.000.0004368599.763693199271302000000000.000.000.000.000.000.000.000.000.2411368599.763693199291782000000000.000.000.000.000.000.000.000.000.240.000.000.008015368599.763693199295412000000000.000.000.000.000.000.000.000.000.2422368599.763693199279252000000000.000.000.000.000.000.000.000.000.240.000.000.008526368599.763693199283442000000000.000.000.000.000.000.000.000.000.2433368599.763693199297892000000000.000.000.000.000.000.000.000.000.240.000.000.008037368599.763693199268922000000000.000.000.000.000.000.000.000.000.24
As expected the Busy% is now close to the 100%.
Conclusion
In this article we have seen that processor power management has significant effect on response times with Hasura. Using the performance governor and disabling idle states improves the average latency by almost 50%. A couple of caveats to be aware of though:
- With wrk2's, measured latencies are [only] accurate to a +/- ~1 ms granularity, due to OS sleep time behavior.
- Disabling idle states/using the performance governor has the effect of also consuming more power. In particular disabling all idle states means that the CPU is running at peak frequency continuously. You might want to experiment with disabling some of the deeper C-states and leaving the shallower ones on.
We have also not tried these in production and these are not official recommendations. However, if you do try these techniques out, tweet to us at @HasuraHQ or join us on Discord for more discussions on Hasura & GraphQL! --> discord.gg/hasura
Sign up for our newsletter to know when we publish new articles. --> http://eepurl.com/dBUfJ5
Top comments (0)