未验证 提交 5b044489 编写于 作者: N nancyzrh 提交者: GitHub

Update performance doc (#4310)

* update performance tool

* update performance doc
上级 c551d42f
......@@ -7,25 +7,25 @@ weight = 5
## 目标
对Sharding-JDBC,Sharding-Proxy及MySQL进行性能对比。从业务角度考虑,在基本应用场景(单路由,主从+脱敏+分库分表,全路由)下,INSERT+UPDATE+DELETE通常用作一个完整的关联操作,用于性能评估,而SELECT关注分片优化可用作性能评估的另一个操作;而主从模式下,可将INSERT+SELECT+DELETE作为一组评估性能的关联操作。为了更好的观察效果,设计在一定数据量的基础上,20并发线程持续压测半小时,进行增删改查性能测试
对Sharding-JDBC,Sharding-Proxy及MySQL进行性能对比。从业务角度考虑,在基本应用场景(单路由,主从+脱敏+分库分表,全路由)下,INSERT+UPDATE+DELETE通常用作一个完整的关联操作,用于性能评估,而SELECT关注分片优化可用作性能评估的另一个操作;而主从模式下,可将INSERT+SELECT+DELETE作为一组评估性能的关联操作。为了更好的观察效果,设计在一定数据量的基础上,使用jmeter 20并发线程持续压测半小时,进行增删改查性能测试,且每台机器部署一个MySQL实例
## 测试场景
#### 单路由
在1000数据量的基础上分库分表,根据`id`分为4个库,根据`k`分为1024个表,查询操作路由到单库单表。
在1000数据量的基础上分库分表,根据`id`分为4个库,部署在同一台机器上,根据`k`分为1024个表,查询操作路由到单库单表。
#### 主从
基本主从场景,设置一主库一从库,在10000数据量的基础上,观察读写性能。
基本主从场景,设置一主库一从库,部署在两台不同的机器上,在10000数据量的基础上,观察读写性能。
#### 主从+脱敏+分库分表
在1000数据量的基础上,根据`id`分为4个库,根据`k`分为1024个表,`c`使用aes加密,`pad`使用md5加密,查询操作路由到单库单表。
在1000数据量的基础上,根据`id`分为4个库,部署在四台不同的机器上,根据`k`分为1024个表,`c`使用aes加密,`pad`使用md5加密,查询操作路由到单库单表。
#### 全路由
在1000数据量的基础上,分库分表,根据`id`分为4个库,根据`k`分为1个表,查询操作使用全路由。
在1000数据量的基础上,分库分表,根据`id`分为4个库,部署在四台不同的机器上,根据`k`分为1个表,查询操作使用全路由。
## 测试环境搭建
......
......@@ -8,27 +8,27 @@ weight = 5
## Target
The performance of Sharding-JDBC,Sharding-Proxy and MySQL would be compared here. INSERT & UPDATE & DELETE which regarded as a set of associated operation and SELECT which focus on sharding optimization are used to evaluate performance for the basic scenarios (single route, master slave & encrypt & sharding, full route). While another set of associated operation, INSERT & SELECT & DELETE, is used to evaluate performance for master slave.
To achieve the result better, these tests are performed based on a certain amount of data with 20 concurrent threads for 30 minutes.
To achieve the result better, these tests are performed with jmeter which based on a certain amount of data with 20 concurrent threads for 30 minutes, and one MySQL has been deployed on one machine.
## Test Scenarios
#### Single Route
On the basis of one thousand data volume, four databases that each contains 1024 tables with `id` used for database sharding and `k` used for table sharding are designed for this scenario.
On the basis of one thousand data volume, four databases that are deployed on the same machine and each contains 1024 tables with `id` used for database sharding and `k` used for table sharding are designed for this scenario.
Single route select sql statement is chosen here.
#### Master Slave
One master database and one slave database is designed for this scenario based on ten thousand data volume.
One master database and one slave database, which are deployed on different machines, are designed for this scenario based on ten thousand data volume.
#### Master Slave & Encrypt & Sharding
On the basis of one thousand data volume, four databases that each contains 1024 tables with `id` used for database sharding, `k` used for table sharding, `c` encrypted with aes and `pad` encrypted with md5 are designed for this scenario.
On the basis of one thousand data volume, four databases that are deployed on different machines and each contains 1024 tables with `id` used for database sharding, `k` used for table sharding, `c` encrypted with aes and `pad` encrypted with md5 are designed for this scenario.
Single route select sql statement is chosen here.
#### Full Route
On the basis of one thousand data volume, four databases that each contains one table are designed for this scenario, field `id` is used for database sharding and `k` is used for table sharding.
On the basis of one thousand data volume, four databases that are deployed on different machines and each contains one table are designed for this scenario, field `id` is used for database sharding and `k` is used for table sharding.
Full route select sql statement is chosen here.
## Testing Environment
......
Markdown is supported
0% .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑!
想要评论请 注册