[FLINK-30535] Introduce TTL state based benchmarks

[Zakelly]

As the title says, This PR introduce TTL state based benchmarks. The newly added tests are basically the same as the previous tests, but have been streamlined because the running time is too long with so many parameters.

I also suggest we disable it in the daily run, or only enable it weekly in jenkins since this is time-consuming.

[Zakelly]

@masteryhx @Myasuka would you please take a look? Many thanks~

[Myasuka]

Thanks for creating this PR, I mainly care about the choose of TTL configuration.

[Myasuka]

What's the performance/result change if we tune this expired-seconds configuration?
Say if we increase it to 10 seconds, or decrease it to 3 seconds?

[Zakelly]

Considering that the warm-up will take 10 seconds, 5 seconds is enough for the test to enter the key expiration phase, and it is not too short. I will give a comparison of the results under different configurations.

[Zakelly]

I think it is better to manipulate the TtlTimeProvider to finely control the number of keys eliminated in each iteration. So I customize the TtlTimeProvider and provide an option for the percentage of keys that expired per iteration. This option will affect the result of test especially in valueGet. Here's a running test:

# Benchmark: org.apache.flink.state.benchmark.ttl.TtlValueStateBenchmark.valueGet
# Parameters: (backendType = HEAP, expiredOption = ExpirePercent3PerIteration, stateVisibility = NeverReturnExpired, updateType = OnCreateAndWrite)

# Run progress: 0.00% complete, ETA 00:12:00
# Fork: 1 of 3
# Warmup Iteration   1: 2993.246 ops/ms
# Warmup Iteration   2: 3520.954 ops/ms
# Warmup Iteration   3: 3640.884 ops/ms
# Warmup Iteration   4: 3643.386 ops/ms
# Warmup Iteration   5: 3776.677 ops/ms
# Warmup Iteration   6: 3739.375 ops/ms
# Warmup Iteration   7: 3903.434 ops/ms
# Warmup Iteration   8: 3877.286 ops/ms
# Warmup Iteration   9: 3913.663 ops/ms
# Warmup Iteration  10: 4093.471 ops/ms
Iteration   1: 4117.018 ops/ms
Iteration   2: 4255.166 ops/ms
Iteration   3: 4338.564 ops/ms
Iteration   4: 4439.571 ops/ms
Iteration   5: 4603.235 ops/ms
Iteration   6: 4735.039 ops/ms
Iteration   7: 4896.946 ops/ms
Iteration   8: 5153.644 ops/ms
Iteration   9: 5429.196 ops/ms
Iteration  10: 5772.806 ops/ms

As we can see, as the key expires, the test results increase iteration by iteration. I pick 3% for a predefined value, since there are 20 iterations in each test and we cannot let all the keys expire. WDYT? @Myasuka

[Myasuka]

I like the idea to use expired percent instead of the specific time-to-live. BTW, why choose 3% as the predefined value?

[Zakelly]

There are 20 iterations in each test, 10 rounds warm-up and 10 rounds testing. If 3% is chosen, the testing will cover 70% down to 40% state size, which is a relatively reasonable value (not so big or small).

[Myasuka]

Thanks for the update, I like the idea of letting the fixed data expire better than a configured TTL seconds. Please take a look at my comments.

[Zakelly]

@Myasuka I fixed a compile error and now it's OK. Maybe this repo needs a more swift CI process validating the compilation.
Please let me know if you have any other concern on this PR. Thanks.

[Zakelly]

@Myasuka Kindly remind~

[Myasuka]

Thanks for the update, LGTM.