Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Send commit concurrently in client side #59

Merged
merged 7 commits into from Jul 17, 2022
Merged

Conversation

zuston
Copy link
Member

@zuston zuston commented Jul 16, 2022

What changes were proposed in this pull request?

Sending commit concurrently in client side

Why are the changes needed?

I found when using the LOCALFILE storageType, waiting the commit will cost too much time. To speed up, it can be sent commit concurrently by using thread pool.

Performance Test Case
Using 1000 executors of Spark, single executor 1g/1core to run TeraSort 1TB.

When using LOCALFILE storageType mode, it cost 7.3 min.
And then after applying this PR, it cost 6.1 min

Does this PR introduce any user-facing change?

  1. Introducing the conf of rss.client.data.commit.pool.size, the default value is assigned shuffle server size.

How was this patch tested?

No need

@codecov-commenter
Copy link

codecov-commenter commented Jul 16, 2022

Codecov Report

Merging #59 (e392f1e) into master (e48f74e) will decrease coverage by 0.04%.
The diff coverage is 8.57%.

@@             Coverage Diff              @@
##             master      #59      +/-   ##
============================================
- Coverage     55.21%   55.16%   -0.05%     
+ Complexity     1111     1110       -1     
============================================
  Files           148      148              
  Lines          7953     7962       +9     
  Branches        760      760              
============================================
+ Hits           4391     4392       +1     
- Misses         3321     3328       +7     
- Partials        241      242       +1     
Impacted Files Coverage Δ
.../java/org/apache/hadoop/mapreduce/RssMRConfig.java 87.50% <ø> (ø)
...n/java/org/apache/hadoop/mapreduce/RssMRUtils.java 31.70% <0.00%> (-0.40%) ⬇️
.../java/org/apache/spark/shuffle/RssSparkConfig.java 88.88% <ø> (ø)
...e/uniffle/client/factory/ShuffleClientFactory.java 0.00% <ø> (ø)
...rg/apache/uniffle/client/util/RssClientConfig.java 0.00% <ø> (ø)
...he/uniffle/client/impl/ShuffleWriteClientImpl.java 25.95% <8.82%> (-0.04%) ⬇️
.../apache/uniffle/coordinator/ClientConfManager.java 91.54% <0.00%> (-1.41%) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update e48f74e...e392f1e. Read the comment docs.

@jerqi
Copy link
Contributor

jerqi commented Jul 16, 2022

Do you have performance tests? I guess this pr can't improve the performance. Because the performance bottleneck of commit operation is on the shuffle server in my opinion.

@zuston
Copy link
Member Author

zuston commented Jul 16, 2022

Yes. I tested
I use 1000 executors, single executor 1g/1core to run terasort 1TB.

When using localfile mode, it cost 7.3 min.
And when i apply this PR, it cost 6.1 min

@jerqi

@zuston
Copy link
Member Author

zuston commented Jul 16, 2022

Do you have performance tests? I guess this pr can't improve the performance. Because the performance bottleneck of commit operation is on the shuffle server in my opinion.

As I know the spilling to disk event need to be triggered by client side. So if the previous trigger is blocked, the next one will
not be triggered.

@jerqi
Copy link
Contributor

jerqi commented Jul 16, 2022

We don't recommend to use the storageType LOCALFILE, because it has poor performance. But the improvement is ok for me.

@@ -247,43 +249,57 @@ public SendShuffleDataResult sendShuffleData(String appId, List<ShuffleBlockInfo
return new SendShuffleDataResult(successBlockIds, failedBlockIds);
}

/**
* This method will wait until all shuffle data have been spilled
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

spilled -> flushed.

@jerqi
Copy link
Contributor

jerqi commented Jul 16, 2022

Yes. I tested I use 1000 executors, single executor 1g/1core to run terasort 1TB.

When using localfile mode, it cost 7.3 min. And when i apply this PR, it cost 6.1 min

@jerqi

Please put performance test results into Why are the changes need?

@@ -17,6 +17,8 @@

package org.apache.uniffle.client.util;

import org.apache.hadoop.io.OutputBuffer;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we need this?

private final ForkJoinPool dataTransferPool;

public ShuffleWriteClientImpl(String clientType, int retryMax, long retryIntervalMax, int heartBeatThreadNum,
int replica, int replicaWrite, int replicaRead, boolean replicaSkipEnabled,
int dataTranferPoolSize) {
int dataTranferPoolSize, int commitSenderPoolSize) {
Copy link
Contributor

@jerqi jerqi Jul 16, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We prefer the code style as below

public ShuffleWriteClientImpl(
       String clientType, 
       int retryMax,
       long retryIntervalMax,
       int heartBeatThreadNum,
       int replica,
       int replicaWrite,
       int replicaRead,
       boolean replicaSkipEnabled,
       int dataTranferPoolSize,
       int commitSenderPoolSize) {

public static final String RSS_COMMIT_SENDER_POOL_SIZE =
MR_RSS_CONFIG_PREFIX + RssClientConfig.RSS_COMMIT_SENDER_POOL_SIZE;
public static final int RSS_COMMIT_SENDER_POOL_SIZE_DEFAULT_VALUE =
RssClientConfig.RSS_COMMIT_SENDER_POOL_SIZE_DEFAULT_VALUE;
Copy link
Contributor

@jerqi jerqi Jul 16, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The name's style should be consistent with data_transfer_pool_size. How about data_commit_pool_size?

@jerqi
Copy link
Contributor

jerqi commented Jul 16, 2022

Could you update the document about this feature?

@jerqi
Copy link
Contributor

jerqi commented Jul 16, 2022

4b5389f
In this pr, we use method stream to replace method parallelStream. It may be a bad choice. Method registerShuffleServer use method stream, too. Is it possible to improve performance to use method parallelStream in method registerShuffleServer? Will it create too many forkjoinPool?

@zuston
Copy link
Member Author

zuston commented Jul 16, 2022

If we close the forkjoin pool in the scope of method. I think it’s ok.

@jerqi
Copy link
Contributor

jerqi commented Jul 16, 2022

If we close the forkjoin pool in the scope of method. I think it’s ok.

Ok

@zuston
Copy link
Member Author

zuston commented Jul 16, 2022

We don't recommend to use the storageType LOCALFILE, because it has poor performance. But the improvement is ok for me.

The performance of LOCALFILE looks better than ess. Due to no need to wait data flushed to disk, the MEMORY_LOCALFILE will better.

@zuston
Copy link
Member Author

zuston commented Jul 16, 2022

Besides I think i can submit new PR to let registerShuffleServer do the same optimization

@jerqi
Copy link
Contributor

jerqi commented Jul 16, 2022

Besides I think i can submit new PR to let registerShuffleServer do the same optimization

We'd better have performance tests. RegisterShuffleServer may not cost too much time. The optimization have less effect.

});
});
}).join();
} catch (Exception e) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we use

finally {
   forkJoinPool.shutdownNow();
}

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My fault…..

@jerqi
Copy link
Contributor

jerqi commented Jul 16, 2022

Could you update the document because this pr introduce the user-facing change?

@jerqi jerqi changed the title Sending commit concurrently in client side Send commit concurrently in client side Jul 16, 2022
@zuston
Copy link
Member Author

zuston commented Jul 17, 2022

Done @jerqi

Copy link
Contributor

@jerqi jerqi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@jerqi jerqi merged commit c3616c2 into apache:master Jul 17, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants