Skip to content

3.0_压力测试报告（RdbToRdb）

Jump to bottom
elevenqq edited this page Oct 18, 2018 · 1 revision

场景一：单库_2_单库（Insert）

  • 场景描述
    > 创建一个MysqlTask，负责将ucar_order0数据同步到ucar_order
    > 压测脚本只执行insert操作
    > 压测脚本名称为：db_2_db_insert.jmx
    > 调整Task的各项参数组合，观察不同参数下数据同步的延迟情况

  • 测试结果【非压缩合并】

    Task参数配置 性能指标 work资源监控 mysql资源监控
    压缩合并 线程数 批量写入 BatchSize 是否copy 数据库tps 同步延时 起止时间 cpu使用率 cpu- load network(I/O) cpu 使用率 cpu- load network(I/O)
    否 10　 (是&否) 50　 是 1000 500ms (2017-08-15)
    19:10--19:20    		 24% 0.5 7.37/24.18Mbps 5% 5 33.07/15.63Mbps
    2000 550ms　 (2017-08-15)
    19:40--19:50     		30%　 0.5　 11.59/47.14Mbps　 7.5%　 6 66.84/27.6Mbps　
    3000


    maxdelay
    time    		 197295ms
    catchup
    time    		 15min


    		(2017-08-15)
    20:45--20:55     		35%　 0.5　 11.59/51.61Mbps　 9%　 5 79.23/32.5Mbps　
    否 10 (是&否) 200 是 3000


    maxdelay
    time    		 206768ms
    catchup
    time    		 18min


    		(2017-08-16)
    11:06--11:16     		36.57% 0.52 11.71/52.39Mbps 9.45% 4.89 78.03/31.63Mbps
    否 10 (是&否) 200 否 3000


    maxdelay
    time    		 76271ms
    catchup
    time    		 12min


    		(2017-08-20)
    11:34--11:44     		39.01% 0.4 13.01/58.19Mbps 10.06% 6.03 84.02/33.92Mbps
    说明：
    > 未启动【压缩合并】的时候，【批量写入】设置为是或否意义是一样的，因为非【压缩合并】模式下，系统不支持批量写入
    > 未启动【压缩合并】的时候，【线程数】大小只要比待同步的表数量多，就可以保证充分并发，因为非【压缩合并】模式下，Record按表进行分组
    > 未启动【压缩合并】的时候，【BatchSize】的意义为事务的大小，即：每多少条提交一次
    结论：
    > 上述参数组合情况下，写端最大可支持的Tps在2000~2500之间
    > 测试过程中将batchsize从50调整为200，性能并没有明显提升，说明事务大小并不是关键因素
    > 测试过程中将【是否copy】从是改为否，性能有所提升，但是还是有比较大的延迟，说明此参数组合下，copy耗费的时间不是主要影响因素
    > jmeter产生3000tps的效果只用了3个线程，而datalink用7个线程最大只能达到2500tps，原因主要在于：7个线程并发之后有一个reduce操作，同步速度还是卡在了最慢的那个线程上面，如下所示
    jmeter线程状态图

    jmeter_1
    datalink线程状态图

    datalink_1


  • 测试结果【压缩合并】

    Task参数配置 性能指标 work资源监控 mysql资源监控
    压缩合并 线程数 批量写入 BatchSize 是否copy 数据库tps 同步延时 起止时间 cpu使用率 cpu- load network(I/O) cpu 使用率 cpu- load network(I/O)
    是 10　 否　 --/--　 是 900 500ms (2017-08-16)
    12:16--12:26    		 21% 0.1 7/22.96Mbps 5% 5 31.47/14.92Mbps
    2000 560ms　 (2017-08-16)
    13:15--13:25    		 42%　 0.4 15.36/50.14Mbps　 10%　 8 69/32Mbps　
    3000


    maxdelay
    time    		 251065ms
    catchup
    time    		 15min


    		(2017-08-16)
    13:45--13:55    		 43%　 0.4　 15.4/53.47Mbps　 13.62%　 8 82/38Mbps　
    是 20 否 --/-- 是 3000 600ms (2017-08-16)
    14:35--14:45     		55% 5 22.85/74.17Mbps 17% 9 103.46/49Mbps
    4000


    maxdelay
    time    		 276033ms
    catchup
    time    		 16min


    		(2017-08-16)
    18:45--18:55     		56.94% 3 20.95/70.93Mbps 17% 8 110/52Mbps
    是 40 否 --/-- 是 4000


    maxdelay
    time    		 101708ms
    catchup
    time    		 13min


    		(2017-08-16)
    19:57--20:07     		70% 3 26.77/90.25Mbps 20.84% 8 129/61.07Mbps
    是


    		 10


    		 是


    		 50


    		 是 4000 500ms (2017-08-16)
    20:40--20:50    		 36.86% 0.8 18.35/23.17Mbps 8.52% 7 61.35/44.56Mbps
    6000 550ms (2017-08-18)
    11:45--11:55    		 44.87% 1.08 24.58/23.08Mbps 10.75% 5.96 79.43/62.23Mbps
    8000 697ms (2017-08-17)
    20:44--20:54    		 55% 2.04 30.43/25.94Mbps 13.41% 7.49 98.34/78.64Mbps
    9000 919ms (2017-08-17)
    20:58--21:08    		 59.12% 1.98 33.29/28.06Mbps 14.99% 6.5 107.11/85.74Mbps
    10000


    maxdelay
    time    		 63331ms
    catchup
    time    		 12min


    		(2017-08-18)
    13:00--13:10     		64.80% 2.7 31.49/27.52Mbps 16.32% 7.47 114.55/88.54Mbps
    是 10 是 200 是 10000


    maxdelay
    time    		 42080ms
    catchup
    time    		 11min


    		(2017-08-18)
    13:23--13:33    		 64.89% 3.7 31.03/24.68Mbps 16.25% 7.63 111.38/87.61Mbps
    是 20 是 50 是 10000


    maxdelay
    time    		 34804ms
    catchup
    time    		 11min


    		(2017-08-18)
    13:46--13:56     		67.87% 5.24 32.56/28.51Mbps 16.68% 6.8 114.84/89.51Mbps
    是 20 是 200 是 10000


    maxdelay
    time    		 32619ms
    catchup
    time    		 11min


    		(2017-08-20)
    12:05--12:15     		67.18% 4.32 31.69/25.03Mbps 16.19% 6.98 111.66/88.69Mbps
    是

    		 20

    		 是

    		 200

    		 否

    		 10000 644ms (2017-08-20)
    14:55--15:05     		58.49% 2.31 37.72/30.21Mbps 17.13% 8.23 122.34/98.68Mbps
    12500 3000ms (2017-08-20)
    15:25--15:35     		68.65% 4.42 43.12/34.7Mbps 20.16% 7.84 142.2/114Mbps
    14500


    maxdelay
    time    		 98432ms
    catchup
    time    		 12min


    		(2017-08-20)
    15:48--15:58     		68.11% 4.09 43.65/35.5Mbps 24.16% 7.86 165.91/128.37Mbps
    说明：
    > 【是否copy】对应的配置元素为【重试模式】，当重试模式为【NoAndError】的时候，程序内部不会进行copy操作
    结论：
    > 开启merge，但没有开启batch的情况下，系统最大可支撑的tps为3000，仅比未开启merge的情况高1000个tps
    > 开启merge，并且开启batch，但没有关闭copy的情况下，系统最大可支撑的tps在8000~9000之间
    > 开启merge，并且开启batch，并且关闭copy的情况下，系统最大可支撑的tps在11000~12000之间
    > 在系统延迟时间超过1000ms的临界点，增大线程数和batchsize，达到的效果并不是非常大，还是得靠程序调优解决问题


场景二：单库_2_单库（Insert+Update+[1:1]）

  • 场景描述
    > 创建一个MysqlTask，负责将ucar_order0数据同步到ucar_order
    > 压测脚本对每张表执行1次insert操作，然后从每张表中随机选一条数据，连续执行1次update操作（即：insert和update的比例关系为1:1）
    > 压测脚本名称为：db_2_db_update_1.jmx（ps：为了最大程度接近真实场景，update操作时随机选取的数据控制在最新的10万条数据之内）
    > 调整Task的各项参数，观察不同参数下数据同步的延迟情况

  • 测试结果【非压缩合并】

    Task参数配置 性能指标 work资源监控 mysql资源监控
    压缩合并 线程数 批量写入 BatchSize 是否copy 数据库tps 同步延时 起止时间 cpu使用率 cpu- load network(I/O) cpu 使用率 cpu- load network(I/O)
    否 10　 (是&否) 50　 是 1200

    512ms

     

    		 (2017-08-24)
    09:23--09:33    		 27.34% 0.1 10.88/20.69Mbps 7.08% 6.79 30.91/26.45Mbps
    2000

    534ms

     

    		 (2017-08-24)
    09:47--09:57     		33.21% 0.39 14.48/29.24Mbps 9.33% 8.79 44.32/36.95Mbps
    2800


    maxdelay
    time    		 81034ms
    catchup
    time    		 12min


    		(2017-08-24)
    10:05--10:15     		37.14% 0.73 15.73/34.14Mbps 11.12% 5.77 55.05/45.45Mbps
    结论： 混合场景下，系统的同步性能基本上和单纯insert时相同

     

    测试结果【压缩合并】

    Task参数配置 性能指标 work资源监控 mysql资源监控
    压缩合并 线程数 批量写入 BatchSize 是否copy 数据库tps 同步延时 起止时间 cpu使用率 cpu- load network(I/O) cpu 使用率 cpu- load network(I/O)
    是



    		 10　

    		 否

    		 --/--

    		 是

    		 1200

    512ms


     

    		 (2017-08-21)
    14:15--14:25     		30.57% 0.13 12.09/21/63Mbps 8.23% 4.95 31.24/27.73Mbps
    2000 599ms (2017-08-21)
    14:29--14:39     		40.31% 0.8 18.02/32.13Mbps 12.11% 6.38

    47.58/41.13Mbps
    2800


    maxdelay
    time    		 182791ms
    catchup
    time    		 22min


    		(2017-08-21)
    14:45--14:55     		44.98% 0.66 18.78/34.42Mbps 14.27% 6.13 55.3/49.24Mbps
    是 20 否 --/-- 是 2800 547ms (2017-08-21)
    15:05--15:15     		52.64% 0.53 23.83/42.46Mbps 17.04% 6.77 66.32/58.67Mbps
    4000


    maxdelay
    time    		 230690ms
    catchup
    time    		 15min


    		(2017-08-21)
    15:29--15:39     		57.73% 2.66 25.21/46.33Mbps 20.28% 7.02 75.19/67.13Mbps
    是


    		 10


    		 是


    		 50


    		 是


    		 4000 548ms (2017-08-21)
    17:03--17:13     		42.34% 0.85 24.39/17.59Mbps 12.84 6.47 47.29/66.17Mbps
    5500 601ms (2017-08-21)
    17:41--17:51     		47.77% 1.2 28.91/15.6Mbps 14.74% 7.1 53.59/81.81Mbps
    6500 754ms (2017-08-21)
    18:31--18:41     		50.88% 1.58 32.31/16.1Mbps 16.04% 7 59.29/92.59Mbps
    8500


    maxdelay
    time    		 181384ms
    catchup
    time    		 14min


    		(2017-08-21)
    19:08--19:18     		57.43% 2.63 32.58/15.91Mbps 22% 6.57 76.26/111.5Mbps
    是 20 是 200 否 8500 704ms (2017-08-22)
    13:00--13:10     		56.53% 2.1 42.86/22.68Mbps 22.31% 7.11 81.87/125.56Mbpss
    10000


    maxdelay
    time    		 49094ms
    catchup
    time    		 12min


    		(2017-08-23)
    19:05--19:15     		56.73% 1.68 43.4/23.28Mbps 33.91% 8.61 110.03/165.13Mbps
    结论： > 和单纯insert相比，同步性能要差一些，把参数调整到最优的组合，Tps到10000时仍然出现了延迟
    > 根据该测试结果可以预估，系统可支持的最大tps在9000~10000之间，当然只是预估，具体的性能指标和具体场景有关


Clone this wiki locally