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 2021/01/07 12:48:41 UTC
[GitHub] [shardingsphere] danielzhou888 opened a new issue #8942: Why the performance of interface stress test used by shardingjdbc-4.0.1 is low obviously than not using sub-meter middleware! What we do wrong!
danielzhou888 opened a new issue #8942:
URL: https://github.com/apache/shardingsphere/issues/8942
## Why the performance of interface stress test used by shardingjdbc-4.0.1 is low obviously than not using sub-meter middleware! What we do wrong!
Please help!
We use shardingjdbc as the sub-table middleware of the shop product table, but when we were doing interface stress testing, we found that using sub-meter middleware is much weaker in performance than not using sub-meter middleware.
**The specific instructions are as follows：**
### Application machine hardware parameter configuration
|Index|Value|Remark|
|:--|:--|:--|
|CPU(s)|4||
|Model Name|Intel Xeon Processor (Skylake, IBRS)||
|Memory|8G||
|System|CentOS Linux release 7.6.1810 (Core) ||
|Linux Version|3.10.0-1062.el7.x86_64||
### Interface pressure test preparation
- 
### Result of Interface Stress Test Of Fixed Value Single Shard Key
- 
**In Conclusion：**
From the above figure, we can see that when the shard value is fixed, the overall performance of using the table-sharing middleware and not using the table-sharing middleware is equivalent.
**This result is expected!**
### Result of Interface Stress Test Of Random Value Single or Multi Shard Key
- 
**In Conclusion：**
1. Single Random Shard Value：
- 
- We can see that under the same concurrency, the performance index throughput is 4 times that of using sub-table middleware without using sub-table middleware.
- We can see that under the same concurrency, the average response time of performance indicators is 3 times that of using sub-table middleware without using sub-table middleware.
2. Multi Random Shard Value:
- 
- We can see that under the same concurrency, the performance index throughput is 5 times that of using sub-table middleware without using sub-table middleware.
- We can see that under the same concurrency, the average response time of performance indicators is 5 times that of using sub-table middleware without using sub-table middleware.
### Database machine load
- 
- 
### Our own guess
- Fixed Value Single Shard Key：Shardingjdbc just does SQL analysis and routes all requests to a fixed sub-table. At this time, the main table and sub-table are cached in the system, and the pressure on the database level is quite.
- Random Value Single Or Multi Shard Key：When concurrently stressing the random sharding key value, when the sharding table is not used, only the main table is requested. The database has a system cache that can hit the cache, so the response is fast; when the sharding table is turned on, different sharding key values are routed to different When the request arrives in the database, it cannot hit the system cache well, so it brings huge pressure to the database. As a result, the CPU soars, the overall application service encounters bottlenecks, the throughput is degraded, and the response slows.
### We need developers to help analyze
We want to find out the specific reasons, whether we have made an error in the way of use and configuration, or where is the problem?
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [shardingsphere] tuohai666 commented on issue #8942: Why the performance of interface stress test used by shardingjdbc-4.0.1 is low obviously than not using sub-meter middleware! What we do wrong!
Posted by GitBox <gi...@apache.org>.
tuohai666 commented on issue #8942:
URL: https://github.com/apache/shardingsphere/issues/8942#issuecomment-763317167
@danielzhou888
Beside, I don't think the 1st conclusion meet expectation. 'On' will never faster than 'Off' in the same env, but the case shows the opposite result. It's important to find out what happened.
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [shardingsphere] tuohai666 commented on issue #8942: Why the performance of interface stress test used by shardingjdbc-4.0.1 is low obviously than not using sub-meter middleware! What we do wrong!
Posted by GitBox <gi...@apache.org>.
tuohai666 commented on issue #8942:
URL: https://github.com/apache/shardingsphere/issues/8942#issuecomment-807892529
@danielzhou888
I have improved the performance recently, please refer to #9616 and #9826 .
The TPS is proved to be increased by 12% and 15% respectively by sysbench test result of ShardingSphere-Proxy. The CPU load also decreased significantly.
It's expected that the ShardingSphere-JDBC can get the similiar result.
These two PRs will be included in the next release, may be 5.0.0-RC1.
--
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [shardingsphere] tuohai666 commented on issue #8942: Why the performance of interface stress test used by shardingjdbc-4.0.1 is low obviously than not using sub-meter middleware! What we do wrong!
Posted by GitBox <gi...@apache.org>.
tuohai666 commented on issue #8942:
URL: https://github.com/apache/shardingsphere/issues/8942#issuecomment-763314967
@danielzhou888 Can you provide more information?
1. What is this host used for? When to use?
2. What is this host used for?
3. Jmeter run in this host right? What's its hardware env?
4. What's the MySQL server's hardware env?
5. Please provide the configuration file of shardingjdbc.
6. Please provide the SQLs of all the test cases.
7. Can you prove the test cases do used PreparedStatement in the 2nd scenario? (show codes, etc..)
8. How you calculate mulit-shop tps when the switch turned 'off'? I mean if shardingjdbc route to 3 shops for 1 logic SQL, we count 1. Meanwhile, when the swith turend off, 3 actual SQLs to 3 shop count as 1 or 3?
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [shardingsphere] tuohai666 closed issue #8942: Why the performance of interface stress test used by shardingjdbc-4.0.1 is low obviously than not using sub-meter middleware! What we do wrong!
Posted by GitBox <gi...@apache.org>.
tuohai666 closed issue #8942:
URL: https://github.com/apache/shardingsphere/issues/8942
--
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org