You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ozone.apache.org by GitBox <gi...@apache.org> on 2022/04/07 05:18:30 UTC
[GitHub] [ozone] cchenax opened a new pull request, #3280: HDDS-6503 EC: Add ec write channel
cchenax opened a new pull request, #3280:
URL: https://github.com/apache/ozone/pull/3280
## What changes were proposed in this pull request?
because of the write channel use the XceiverServerRatis，the ec write and read use the XceiverServerGrpc, so we need to split the write and read channel to improve the performance
## What is the link to the Apache JIRA
https://issues.apache.org/jira/browse/HDDS-6503
## How was this patch tested?
ci
--
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.
To unsubscribe, e-mail: issues-unsubscribe@ozone.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@ozone.apache.org
For additional commands, e-mail: issues-help@ozone.apache.org
[GitHub] [ozone] fapifta commented on pull request #3280: HDDS-6503 EC: Add ec write channel
Posted by GitBox <gi...@apache.org>.
fapifta commented on PR #3280:
URL: https://github.com/apache/ozone/pull/3280#issuecomment-1091596058
I have a couple of problems here also... Let me explain.
In the GRPC client we do use async requests for reads, and for EC we do so for writes as well. (See the shouldBlockAndWaitAsyncreply method in XceiverClientGrpc class and in ECXCeiverClientGrpc class on the EC branch, and the usage of the method.)
What this effectively means is that all the queries are async on the client side for EC, so they hit the server in parallel from the same client as the client requests.
Let's see the server side...
We have a netty server inside the XCeiverServerGrpc which uses a configured number of threads to process requests with GrpcXcevierService configured as a service endpoint. Inside netty, the request processing threads can be hit by a request in parallel, and the request processing starts inside the netty worker thread. Even though we use stream based grpc communication, for every request on the client side, we open a request stream to the server, and just send one message and wait for it to complete, so the server will process every request in parallel within the netty worker thread.
All in all this means that for EC we send the requests in parallel (and syncronize what needs to be syncronized in a higher level), while we process the requests on the server side in parallel.
For me to believe that it gives a better performance to add one more port on the server side to process read and write request in a different server side netty instance needs hard proof, either by benchmarks or by a very well formed reasoning. I would not go and just add one more port and one more server side service implementation for that based on what I know so far for sure.
There is one more hassle with adding a new port name, please see the problems specific to extending the port list inside the DN in HDDS-4731 JIRA ticket, that problem has to be managed in this PR before merging the proposed changes.
--
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.
To unsubscribe, e-mail: issues-unsubscribe@ozone.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@ozone.apache.org
For additional commands, e-mail: issues-help@ozone.apache.org
[GitHub] [ozone] github-actions[bot] commented on pull request #3280: HDDS-6503 EC: Add ec write channel
Posted by GitBox <gi...@apache.org>.
github-actions[bot] commented on PR #3280:
URL: https://github.com/apache/ozone/pull/3280#issuecomment-1192052526
Thank you very much for the patch. I am closing this PR __temporarily__ as there was no activity recently and it is waiting for response from its author.
It doesn't mean that this PR is not important or ignored: feel free to reopen the PR at any time.
It only means that attention of committers is not required. We prefer to keep the review queue clean. This ensures PRs in need of review are more visible, which results in faster feedback for all PRs.
If you need ANY help to finish this PR, please [contact the community](https://github.com/apache/hadoop-ozone#contact) on the mailing list or the slack channel."
--
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.
To unsubscribe, e-mail: issues-unsubscribe@ozone.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@ozone.apache.org
For additional commands, e-mail: issues-help@ozone.apache.org
[GitHub] [ozone] github-actions[bot] closed pull request #3280: HDDS-6503 EC: Add ec write channel
Posted by GitBox <gi...@apache.org>.
github-actions[bot] closed pull request #3280: HDDS-6503 EC: Add ec write channel
URL: https://github.com/apache/ozone/pull/3280
--
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.
To unsubscribe, e-mail: issues-unsubscribe@ozone.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@ozone.apache.org
For additional commands, e-mail: issues-help@ozone.apache.org
[GitHub] [ozone] adoroszlai commented on pull request #3280: HDDS-6503 EC: Add ec write channel
Posted by GitBox <gi...@apache.org>.
adoroszlai commented on PR #3280:
URL: https://github.com/apache/ozone/pull/3280#issuecomment-1171649216
/pending
--
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.
To unsubscribe, e-mail: issues-unsubscribe@ozone.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@ozone.apache.org
For additional commands, e-mail: issues-help@ozone.apache.org
[GitHub] [ozone] fapifta commented on pull request #3280: HDDS-6503 EC: Add ec write channel
Posted by GitBox <gi...@apache.org>.
fapifta commented on PR #3280:
URL: https://github.com/apache/ozone/pull/3280#issuecomment-1096350153
@cchenax Even addressing the enum change related problems won't answer the question why do you want to introduce a separate port for handling EC related requests...
As I stated all requests are processed in a parallel fashion already, so I really would like to see reasoning or proof about how speed is changing with introducing a new server port.
--
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.
To unsubscribe, e-mail: issues-unsubscribe@ozone.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@ozone.apache.org
For additional commands, e-mail: issues-help@ozone.apache.org
[GitHub] [ozone] cchenax commented on pull request #3280: HDDS-6503 EC: Add ec write channel
Posted by GitBox <gi...@apache.org>.
cchenax commented on PR #3280:
URL: https://github.com/apache/ozone/pull/3280#issuecomment-1094280579
> What is the performance problem you have observed with the current approach and why is it bad if EC reads and writes use the RATIS or STANDALONE ports? I don't think we want a specific port for EC reads and writes. They should be able to go over the same existing ports. Reading and writing EC blocks is the same as for STANDLONE blocks at the moment.
> I have a couple of problems here also... Let me explain.
>
> In the GRPC client we do use async requests for reads, and for EC we do so for writes as well. (See the shouldBlockAndWaitAsyncreply method in XceiverClientGrpc class and in ECXCeiverClientGrpc class on the EC branch, and the usage of the method.)
>
> What this effectively means is that all the queries are async on the client side for EC, so they hit the server in parallel from the same client as the client requests.
>
> Let's see the server side... We have a netty server inside the XCeiverServerGrpc which uses a configured number of threads to process requests with GrpcXcevierService configured as a service endpoint. Inside netty, the request processing threads can be hit by a request in parallel, and the request processing starts inside the netty worker thread. Even though we use stream based grpc communication, for every request on the client side, we open a request stream to the server, and just send one message and wait for it to complete, so the server will process every request in parallel within the netty worker thread.
>
> All in all this means that for EC we send the requests in parallel (and syncronize what needs to be syncronized in a higher level), while we process the requests on the server side in parallel.
>
> For me to believe that it gives a better performance to add one more port on the server side to process read and write request in a different server side netty instance needs hard proof, either by benchmarks or by a very well formed reasoning. I would not go and just add one more port and one more server side service implementation for that based on what I know so far for sure.
>
> There is one more hassle with adding a new port name, please see the problems specific to extending the port list inside the DN in [HDDS-4731](https://issues.apache.org/jira/browse/HDDS-4731) JIRA ticket, that problem has to be managed in this PR before merging the proposed changes.
ok，thank you very much, I will see this add port patch.
--
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.
To unsubscribe, e-mail: issues-unsubscribe@ozone.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@ozone.apache.org
For additional commands, e-mail: issues-help@ozone.apache.org
[GitHub] [ozone] cchenax commented on pull request #3280: HDDS-6503 EC: Add ec write channel
Posted by GitBox <gi...@apache.org>.
cchenax commented on PR #3280:
URL: https://github.com/apache/ozone/pull/3280#issuecomment-1097669259
> @cchenax Even addressing the enum change related problems won't answer the question why do you want to introduce a separate port for handling EC related requests... As I stated all requests are processed in a parallel fashion already, so I really would like to see reasoning or proof about how speed is changing with introducing a new server port.
ok, then when I take a hard proof test report I will send to you.
--
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.
To unsubscribe, e-mail: issues-unsubscribe@ozone.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@ozone.apache.org
For additional commands, e-mail: issues-help@ozone.apache.org
[GitHub] [ozone] fapifta commented on pull request #3280: HDDS-6503 EC: Add ec write channel
Posted by GitBox <gi...@apache.org>.
fapifta commented on PR #3280:
URL: https://github.com/apache/ozone/pull/3280#issuecomment-1098341798
Alright, I would be very curious about the why, if there is a significant difference, but I still believe there won't be. Let us know if you have the numbers. Thank you very much for taking the time to measure and test it out!
--
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.
To unsubscribe, e-mail: issues-unsubscribe@ozone.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@ozone.apache.org
For additional commands, e-mail: issues-help@ozone.apache.org
[GitHub] [ozone] sodonnel commented on pull request #3280: HDDS-6503 EC: Add ec write channel
Posted by GitBox <gi...@apache.org>.
sodonnel commented on PR #3280:
URL: https://github.com/apache/ozone/pull/3280#issuecomment-1091354243
What is the performance problem you have observed with the current approach and why is it bad if EC reads and writes use the RATIS or STANDALONE ports? I don't think we want a specific port for EC reads and writes. They should be able to go over the same existing ports. Reading and writing EC blocks is the same as for STANDLONE blocks at the moment.
--
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.
To unsubscribe, e-mail: issues-unsubscribe@ozone.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@ozone.apache.org
For additional commands, e-mail: issues-help@ozone.apache.org