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: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to