You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@flink.apache.org by GitBox <gi...@apache.org> on 2020/10/21 10:01:27 UTC

[GitHub] [flink-benchmarks] zhijiangW commented on pull request #4: [FLINK-19745][network] Supplement micro-benchmark for bounded blocking partition in remote channel case

zhijiangW commented on pull request #4:
URL: https://github.com/apache/flink-benchmarks/pull/4#issuecomment-713456675


   @pnowojski , thanks for the quick review and the discussions. I will share some previous thoughts about the above concerns.
   
   > Does your new benchmark has any local channels as well?
   
   The new benchmark is purely remote channels without local, as I setup only one slot per TM.  There are two considerations here:
   
   - Actually we do not really need local channels in my followup network improvements. And the local channels have already been covered in previous `BlockingPartitionBenchmark`.
   
   - I guess it is hard to control the determined behavior if we allow both remote and local channels. E.g. when we run the benchmark multiple times, the number of local channels might be different for every time, which might effect the benchmark results. So I think it would be better and stable to benchmark separately for purely local/remote channels as now.
   
   As for the above alternatives, 
   
   - Option 2: I really considered whether to refactor/make use of previous `BlockingPartitionBenchmark` when introduce this new one. But I found that `BlockingPartitionBenchmark` is mainly for the compression variable for different types(file/mmap), so the remote channel scenario is not necessary for the compression, then I keep the compression variable as a separate one. 
   
   - Option 3: As I explained above I am wondering the mixed remote and local channel might not be stable for every schedule/deployment, then it would affect the benchmark results.
   
   In summary I a bit prefer to the first option if you also agree, then we can see how to adjust them if really necessary future. :)
   


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org