[GitHub] [shardingsphere] linghengqian commented on issue #8527: sharding-proxy performance

[GitBox <gi...@apache.org>]

linghengqian commented on issue #8527:
URL: https://github.com/apache/shardingsphere/issues/8527#issuecomment-1147367228

   @mygitdds 
   
   - The following are my personal views.
   
    - https://github.com/apache/shardingsphere/issues/13957 has taken a big step, I'm still concerned about the fact that the carrier thread is pinned due to the frequent switching of non-blocking and blocking tasks within the project. Because under Netty's event-driven model, thread blocking will greatly affect the overall performance, although this situation can put out additional thread scheduling, but if the ACTUAL USE OF JDBC pool, the cost of additional processing is too large, from God's point of view, the performance of the project is broken by a few blocking threads is difficult to stretch. 
   
   - If we can open the Reactive link, I prefer to introduce an R2DBC Driver that implements R2DBC SPI on ShardingSphere, and only by introducing Reactor-like responsive libraries can the overall throughput be liberated. R2DBC SPI as a low-level protocol requires R2DBC Drivers to be built on top of asynchronous http and grpc clients (even RSocket that are difficult to track metadata, hilariously) because its network transport protocol is not the same as JDBC. 
   
   - Since `ShardingSphere 5.1.2` exposes SPI for Driver, I'd like to know what you think？


-- 
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: notifications-unsubscribe@shardingsphere.apache.org

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