You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Great progress has been made in presentation than the previous one.
We have reviewed the site and found several issues need to be resolved:
For text:
All mysql change to MySQL.
Modules can be Sharding-JDBC/Sharding-Proxy while can not be sharding/sharding proxy/shardingproxy/sharding_proxy/sharding jdbc/shardingjdbc/sharding_jdbc.
The general order of the TPS in a compared performance is: MySQL > sharding-jdbc > sharding-proxy. But we can find several exceptions like the UPDATE case in https://shardingsphere.apache.org/benchmark/#/sharding-proxy-master-slave-sharding. I this case sharding-proxy > sharding-jdbc. We need to check the test environment and find the root cause. Of course, it does not meen there's no bugs in sharding-jdbc or sharding-proxy.
For the case SELECT in https://shardingsphere.apache.org/benchmark/#/mysql-vs-sharding, the TPS of sharding-proxy is much lower than MySQL. We need to find out whether the case is reasonable or not. Or the performance of sharding-proxy need to be improved.
Our benchmark site is available right now: https://shardingsphere.apache.org/benchmark/
Great progress has been made in presentation than the previous one.
We have reviewed the site and found several issues need to be resolved:
For text:
All mysql change to MySQL.
Modules can be Sharding-JDBC/Sharding-Proxy while can not be sharding/sharding proxy/shardingproxy/sharding_proxy/sharding jdbc/shardingjdbc/sharding_jdbc.
Explicit point out this(https://shardingsphere.apache.org/benchmark/#/mysql-vs-sharding) is a loss test.
There's no VS statement in:
https://shardingsphere.apache.org/benchmark/#/sharding-proxy-master-slave
https://shardingsphere.apache.org/benchmark/#/sharding-proxy-master-slave-sharding
https://shardingsphere.apache.org/benchmark/#/sharding-proxy-single-database-single-table
Compared with:
https://shardingsphere.apache.org/benchmark/#/shardingjdbc-vs-shardingproxy-encrypt
https://shardingsphere.apache.org/benchmark/#/shardingjdbc-vs-shardingproxy-sharding-encrypt
Please find a way to describe who vs who clearly.
Maybe we can remove VS for all cases are VS.
For data:
The general order of the TPS in a compared performance is: MySQL > sharding-jdbc > sharding-proxy. But we can find several exceptions like the UPDATE case in https://shardingsphere.apache.org/benchmark/#/sharding-proxy-master-slave-sharding. I this case sharding-proxy > sharding-jdbc. We need to check the test environment and find the root cause. Of course, it does not meen there's no bugs in sharding-jdbc or sharding-proxy.
For the case SELECT in https://shardingsphere.apache.org/benchmark/#/mysql-vs-sharding, the TPS of sharding-proxy is much lower than MySQL. We need to find out whether the case is reasonable or not. Or the performance of sharding-proxy need to be improved.
For cases:
There's no SELECT case in:
https://shardingsphere.apache.org/benchmark/#/sharding-proxy-master-slave
There're no SELECT and INSERT cases in:
https://shardingsphere.apache.org/benchmark/#/sharding-proxy-master-slave-sharding
The text was updated successfully, but these errors were encountered: