You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@shardingsphere.apache.org by GitBox <gi...@apache.org> on 2022/10/10 06:44:20 UTC
[GitHub] [shardingsphere] mygitdds opened a new issue, #8527: sharding-proxy performance
mygitdds opened a new issue, #8527:
URL: https://github.com/apache/shardingsphere/issues/8527
Since it is the agent provided, I read the source code. When I connect to MySQL, I still use the driver provided by mysql, and the overall implementation is in Java. In this way, I / O interaction with MySQL will cause thread blocking in kernel mode, which leads to low performance. I suggest go, or vertx.
--
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.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [shardingsphere] github-actions[bot] commented on issue #8527: sharding-proxy performance
Posted by GitBox <gi...@apache.org>.
github-actions[bot] commented on issue #8527:
URL: https://github.com/apache/shardingsphere/issues/8527#issuecomment-1272350986
Hello , this issue has not received a reply for several days.
This issue is supposed to be closed.
--
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
[GitHub] [shardingsphere] TeslaCN commented on issue #8527: sharding-proxy performance
Posted by GitBox <gi...@apache.org>.
TeslaCN commented on issue #8527:
URL: https://github.com/apache/shardingsphere/issues/8527#issuecomment-1365564770
We have tried using Vert.x in ShardingSphere-Proxy. And I have tried integrate [ShardingSphere with Vert.x API](https://github.com/TeslaCN/shardingsphere-vert.x). But the improvement is not as large as expected.
Finally we found the I/O performance was not the key of performance issue. The CPU cost of calculation route, rewrite is the largest bottleneck of performance.
At present, we are trying to reduce CPU cost of kernel. Such as https://github.com/apache/shardingsphere/issues/21223.
SInce this issue has been inactive for a while, I'm closing it for now.
--
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
[GitHub] [shardingsphere] TeslaCN closed issue #8527: sharding-proxy performance
Posted by GitBox <gi...@apache.org>.
TeslaCN closed issue #8527: sharding-proxy performance
URL: https://github.com/apache/shardingsphere/issues/8527
--
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
[GitHub] [shardingsphere] github-actions[bot] closed issue #8527: sharding-proxy performance
Posted by GitBox <gi...@apache.org>.
github-actions[bot] closed issue #8527: sharding-proxy performance
URL: https://github.com/apache/shardingsphere/issues/8527
--
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
[GitHub] [shardingsphere] linghengqian commented on issue #8527: sharding-proxy performance
Posted by 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