By using AWS re:Post, you agree to the AWS re:Post Terms of Use
AWS re:Postre:Post
About re:Post

Why does the Aurora PostgreSQL Serverless instance exhibit poor performance and instability?

0

Hello, I plan to use Aurora PostgreSQL Serverless instances, but I've encountered two issues with Aurora PostgreSQL. Can someone explain the causes of these issues and whether they can be resolved? Thank you very much. Here are the details:

Issue 1: Poor Performance of Aurora PostgreSQL

In the same AWS region & availability zone, and same VPC, I deployed two ECS instances (32vCPU, 64GB RAM) and one Aurora PostgreSQL Serverless instance. Using PostgreSQL’s built-in pgbench for performance testing, I found:

Read-only performance of Aurora is ~10x worse than a self-hosted PostgreSQL on EC2!

Read-write performance gap is 5x compared to the self-hosted instance!

1. Background Information
   a. Aurora PostgreSQL Configuration:
       Elastic scaling: 1vCPU/2GB – 256vCPU/512GB
       Storage: Aurora I/O-Optimized
       Database parameters: Default settings
   b. Self-Hosted PostgreSQL on EC2's Configuration:
       EC2 Instance: c5a.8xlarge (32vCPU), gp3 SSD (3000 IOPS, 125MB/s throughput, 500GB)
       postgresql.conf:
            max_wal_size=100GB  
            shared_buffers=16GB  
            wal_buffers=64MB  
            max_connections=1000  
            listen_addresses='*'  
       pg_hba.conf:  host  all  all  0.0.0.0/0  md5  

2. Test Details
   Data volume: 50 million records
   Data import: pgbench -i -s 500 (table pgbench_accounts: 6GB, index pgbench_accounts_pkey: 1GB)

3. Test Steps
    Read-only test: 512 concurrent clients, run for 300 seconds.
    pgbench -M prepared -n -r -P 1 -f ./ro.sql -c 512 -j 512 -T 300 -D scale=500 -D range=50000000 -h **** -U postgres postgres
    Read-write test: 256 concurrent clients, run for 300 seconds.
    pgbench -M prepared -n -r -P 1 -f ./rw.sql -c 256 -j 256 -T 300 -D scale=500 -D range=50000000 -h **** -U postgres postgres

4. Test results
    a. Aurora instance：
             Read-only:   41615 TPS
             Read-write:  8056 TPS
    b. Self-Hosted PostgreSQL on EC2:
             Read-only:   515795 TPS
             Read-write:  41131 TPS

Issue 2: Unstable Performance with Low TPS Spikes

During testing, Aurora PostgreSQL frequently experiences 1–2 second periods of extremely low TPS, while the self-hosted EC2 instance remains stable. Is this caused by Aurora’s automatic scaling leading to performance degradation? I appreciate any insights into the root causes and potential solutions for these issues!

I have conducted multiple tests, and these two issues keep occurring consistently. I really appreciate your answers :）

Topics
AWS Well-Architected FrameworkDatabase
Tags
Performance EfficiencyAmazon Aurora Serverless
Language
English
TestUser
asked 15 days ago89 views
2 Answers
0

The performance and stability issues you're experiencing with Aurora PostgreSQL Serverless can be attributed to several factors:

  1. Scaling behavior: Aurora Serverless v2 dynamically adjusts capacity based on workload. This can lead to periodic performance fluctuations, especially during scaling events. The 1-2 second periods of low TPS you observed are likely due to these scaling operations.

  2. Capacity settings: Your current configuration allows scaling from 1 vCPU/2GB to 256 vCPU/512GB. This wide range can cause slower scaling, as it takes longer to scale up from a very low capacity to a high one. Consider adjusting your minimum capacity to a higher value to reduce scaling time and improve performance during sudden workload spikes.

  3. Connection management: Aurora Serverless v2 caps the maximum connections at 2,000 for PostgreSQL when the minimum capacity is set to 0.5 ACUs or lower. This could be limiting your concurrency, especially in your read-only test with 512 concurrent clients.

  4. Resource utilization: The performance gap between Aurora and the self-hosted PostgreSQL could be due to differences in resource allocation and utilization. Aurora's serverless nature means it's optimizing for cost and scalability, which can sometimes come at the expense of raw performance compared to a dedicated instance.

  5. Configuration differences: Your self-hosted PostgreSQL has custom configurations (e.g., large shared_buffers, max_wal_size) which are optimized for your workload. Aurora Serverless uses default settings which may not be ideal for your specific use case.

To address these issues:

  1. Monitor your cluster's performance using Amazon CloudWatch. Track metrics like ACU usage, connections, and CPU utilization to identify patterns of resource exhaustion.

  2. Adjust your Aurora Serverless v2 capacity settings. Consider increasing the minimum ACU to handle sudden spikes better and reduce scaling time.

  3. Optimize your database parameters. Be aware that some non-default parameter values might prevent efficient scaling.

  4. Consider using a connection pooler like Amazon RDS Proxy to manage connections more efficiently.

  5. Review and optimize your queries and database schema to reduce resource consumption.

  6. If consistent high performance is crucial, you might want to consider using a provisioned Aurora instance instead of Serverless, as it provides more predictable performance.

Remember that Aurora Serverless is designed for workloads with variable demand, prioritizing cost-efficiency and automatic scaling over raw performance. If your workload requires consistent high performance, a provisioned instance might be more suitable.
Sources
AppSync + Aurora Serverless V2 - The request was throttled because of insufficient resources on the database | AWS re:Post
Performance and scaling for Aurora Serverless v2 - Amazon Aurora
Using Amazon CloudWatch metrics to analyze resource usage for Aurora PostgreSQL - Amazon Aurora

profile picture
re:Post Agent
answered 15 days ago
profile picture
EXPERT
Gary Mclean
reviewed 14 days ago
  • TestUser
    14 days ago

    I adjusted the scaling range of the Aurora Serverless instance, and the test results are as follows:

    1. Scaling range 32U-256U： read-only: 138214 TPS read-write: 16201 TPS

    2. Scaling range 64U-256U： read-only: 260727 TPS read-write: 22766 TPS

    3. Scaling range 128U-256U： read-only: 457775 TPS read-write: 28510 TPS

    4. Scaling range 255U-256U： read-only: 627576 TPS read-write: 29391 TPS

    The previous test results for Self-Hosted PostgreSQL on EC2 (32U): read-only: 515795 TPS read-write: 41131 TPS

    However, for the PostgreSQL instance self-built on EC2, the CPU utilization has reached over 98% during the testing process. If the number of CPU cores is increased, the performance of the database will be better.

0

I wasn't able to successfully upload some pictures of the testing process, so I'll paste them in text form.

1. (Issue 1) Aurora Read-only: 41615 TPS
progress: 290.0 s, 51194.0 tps, lat 9.998 ms stddev 11.735, 0 failed
progress: 291.0 s, 52164.2 tps, lat 9.679 ms stddev 8.454, 0 failed
progress: 292.0 s, 48171.8 tps, lat 10.783 ms stddev 7.151, 0 failed
progress: 293.0 s, 52247.5 tps, lat 9.763 ms stddev 5.714, 0 failed
progress: 294.0 s, 55091.7 tps, lat 9.322 ms stddev 4.660, 0 failed
progress: 295.0 s, 55420.9 tps, lat 9.235 ms stddev 5.181, 0 failed
progress: 296.0 s, 52081.9 tps, lat 9.847 ms stddev 6.740, 0 failed
progress: 297.0 s, 53252.1 tps, lat 9.606 ms stddev 7.809, 0 failed
progress: 298.0 s, 52744.8 tps, lat 9.706 ms stddev 4.729, 0 failed
progress: 299.0 s, 52302.5 tps, lat 9.768 ms stddev 4.428, 0 failed
transaction type: ./ro.sql
scaling factor: 1
query mode: prepared
number of clients: 512
number of threads: 512
maximum number of tries: 1
duration: 300 s
number of transactions actually processed: 12461589
number of failed transactions: 0 (0.000%)
latency average = 12.294 ms
latency stddev = 40.936 ms
initial connection time = 776.020 ms
tps = 41615.129011 (without initial connection time)
statement latencies in milliseconds and failures:
         0.001           0  \set aid random_gaussian(1, :range, 10.0)
        12.301           0  SELECT abalance FROM pgbench_accounts WHERE aid = :aid;

2. (Issue 1) Aurora Read-write:  8056 TPS 
progress: 290.0 s, 9195.1 tps, lat 27.879 ms stddev 11.908, 0 failed
progress: 291.0 s, 8629.0 tps, lat 29.250 ms stddev 15.213, 0 failed
progress: 292.0 s, 8811.0 tps, lat 29.461 ms stddev 14.373, 0 failed
progress: 293.0 s, 3794.0 tps, lat 64.408 ms stddev 128.920, 0 failed
progress: 294.0 s, 10182.9 tps, lat 26.172 ms stddev 28.557, 0 failed
progress: 295.0 s, 9960.1 tps, lat 25.780 ms stddev 10.778, 0 failed
progress: 296.0 s, 9769.0 tps, lat 26.115 ms stddev 11.699, 0 failed
progress: 297.0 s, 8947.9 tps, lat 28.727 ms stddev 16.778, 0 failed
progress: 298.0 s, 10156.1 tps, lat 25.192 ms stddev 11.260, 0 failed
progress: 299.0 s, 9086.0 tps, lat 28.211 ms stddev 12.667, 0 failed
progress: 300.0 s, 9809.0 tps, lat 25.803 ms stddev 11.537, 0 failed
transaction type: ./rw.sql
scaling factor: 1
query mode: prepared
number of clients: 256
number of threads: 256
maximum number of tries: 1
duration: 300 s
number of transactions actually processed: 2415643
number of failed transactions: 0 (0.000%)
latency average = 31.762 ms
latency stddev = 19.020 ms
initial connection time = 356.357 ms
tps = 8056.899402 (without initial connection time)
statement latencies in milliseconds and failures:
         0.001           0  \set aid random_gaussian(1, :range, 10.0)
         0.000           0  \set bid random(1, 1 * :scale)
         0.000           0  \set tid random(1, 10 * :scale)
         0.000           0  \set delta random(-5000, 5000)
         1.319           0  BEGIN;
         2.124           0  UPDATE pgbench_accounts SET abalance = abalance + :delta WHERE aid = :aid;
         3.471           0  SELECT abalance FROM pgbench_accounts WHERE aid = :aid;
         3.594           0  UPDATE pgbench_tellers SET tbalance = tbalance + :delta WHERE tid = :tid;
         6.705           0  UPDATE pgbench_branches SET bbalance = bbalance + :delta WHERE bid = :bid;
         2.806           0  INSERT INTO pgbench_history (tid, bid, aid, delta, mtime) VALUES (:tid, :bid, :aid, :delta, CURRENT_TIMESTAMP);
        11.756           0  END;

3. (Issue 1) Self-Hosted PostgreSQL on EC2 Read-only: 515795 TPS 
progress: 290.0 s, 529997.8 tps, lat 0.965 ms stddev 1.202, 0 failed
progress: 291.0 s, 528215.8 tps, lat 0.968 ms stddev 1.150, 0 failed
progress: 292.0 s, 520404.2 tps, lat 0.987 ms stddev 1.220, 0 failed
progress: 293.0 s, 522784.6 tps, lat 0.984 ms stddev 1.151, 0 failed
progress: 294.0 s, 522131.5 tps, lat 0.980 ms stddev 1.140, 0 failed
progress: 295.0 s, 526065.7 tps, lat 0.972 ms stddev 1.159, 0 failed
progress: 296.0 s, 524938.8 tps, lat 0.974 ms stddev 1.125, 0 failed
progress: 297.0 s, 524246.2 tps, lat 0.976 ms stddev 1.148, 0 failed
progress: 298.0 s, 525798.2 tps, lat 0.973 ms stddev 1.145, 0 failed
progress: 299.0 s, 526591.0 tps, lat 0.971 ms stddev 1.143, 0 failed
transaction type: ./ro.sql
scaling factor: 1
query mode: prepared
number of clients: 512
number of threads: 512
maximum number of tries: 1
duration: 300 s
number of transactions actually processed: 154661776
number of failed transactions: 0 (0.000%)
latency average = 0.991 ms
latency stddev = 1.156 ms
initial connection time = 299.230 ms
tps = 515795.347443 (without initial connection time)
statement latencies in milliseconds and failures:
         0.001           0  \set aid random_gaussian(1, :range, 10.0)
         1.003           0  SELECT abalance FROM pgbench_accounts WHERE aid = :aid;

4. (Issue 1) Self-Hosted PostgreSQL on EC2 Read-write: 41131 TPS
progress: 290.0 s, 41744.3 tps, lat 6.130 ms stddev 4.307, 0 failed
progress: 291.0 s, 44045.2 tps, lat 5.814 ms stddev 2.918, 0 failed
progress: 292.0 s, 41548.6 tps, lat 6.159 ms stddev 3.478, 0 failed
progress: 293.0 s, 44232.1 tps, lat 5.788 ms stddev 4.630, 0 failed
progress: 294.0 s, 42546.6 tps, lat 6.006 ms stddev 3.525, 0 failed
progress: 295.0 s, 42884.1 tps, lat 5.977 ms stddev 3.527, 0 failed
progress: 296.0 s, 41253.6 tps, lat 6.097 ms stddev 3.056, 0 failed
progress: 297.0 s, 42219.8 tps, lat 6.169 ms stddev 4.931, 0 failed
progress: 298.0 s, 43409.6 tps, lat 5.900 ms stddev 3.596, 0 failed
progress: 299.0 s, 42590.2 tps, lat 6.006 ms stddev 3.536, 0 failed
progress: 300.0 s, 41786.1 tps, lat 6.073 ms stddev 3.274, 0 failed
transaction type: ./rw.sql
scaling factor: 1
query mode: prepared
number of clients: 256
number of threads: 256
maximum number of tries: 1
duration: 300 s
number of transactions actually processed: 12337825
number of failed transactions: 0 (0.000%)
latency average = 6.221 ms
latency stddev = 2.816 ms
initial connection time = 183.716 ms
tps = 41131.105853 (without initial connection time)
statement latencies in milliseconds and failures:
         0.001           0  \set aid random_gaussian(1, :range, 10.0)
         0.001           0  \set bid random(1, 1 * :scale)
         0.000           0  \set tid random(1, 10 * :scale)
         0.000           0  \set delta random(-5000, 5000)
         0.298           0  BEGIN;
         0.430           0  UPDATE pgbench_accounts SET abalance = abalance + :delta WHERE aid = :aid;
         0.334           0  SELECT abalance FROM pgbench_accounts WHERE aid = :aid;
         0.495           0  UPDATE pgbench_tellers SET tbalance = tbalance + :delta WHERE tid = :tid;
         1.173           0  UPDATE pgbench_branches SET bbalance = bbalance + :delta WHERE bid = :bid;
         0.344           0  INSERT INTO pgbench_history (tid, bid, aid, delta, mtime) VALUES (:tid, :bid, :aid, :delta, CURRENT_TIMESTAMP);
         3.151           0  END;

5. (Issue 2) pgbench read only test
progress: 148.0 s, 7920.6 tps, lat 128.996 ms stddev 340.498, 0 failed
progress: 149.0 s, 5807.7 tps, lat 83.374 ms stddev 124.126, 0 failed
progress: 150.0 s, 8657.0 tps, lat 61.044 ms stddev 83.538, 0 failed
progress: 151.0 s, 6554.0 tps, lat 77.148 ms stddev 127.368, 0 failed
progress: 152.0 s, 6654.0 tps, lat 86.573 ms stddev 199.824, 0 failed
progress: 153.0 s, 7545.9 tps, lat 67.037 ms stddev 38.626, 0 failed
progress: 154.0 s, 4315.4 tps, lat 105.384 ms stddev 117.796, 0 failed
progress: 155.0 s, 3943.5 tps, lat 141.732 ms stddev 161.033, 0 failed
progress: 156.0 s, 3936.0 tps, lat 128.262 ms stddev 95.157, 0 failed
progress: 157.0 s, 2536.6 tps, lat 156.432 ms stddev 122.443, 0 failed
progress: 158.0 s, 1611.2 tps, lat 390.370 ms stddev 302.962, 0 failed
progress: 159.0 s, 1452.9 tps, lat 323.331 ms stddev 240.378, 0 failed
progress: 160.0 s, 2841.2 tps, lat 196.888 ms stddev 193.936, 0 failed
progress: 161.0 s, 2441.8 tps, lat 183.003 ms stddev 159.356, 0 failed
progress: 162.0 s, 1385.1 tps, lat 376.395 ms stddev 313.839, 0 failed
progress: 163.0 s, 2994.9 tps, lat 144.565 ms stddev 138.204, 0 failed
progress: 164.0 s, 0.0 tps, lat 0.000 ms stddev 0.000, 0 failed
progress: 165.0 s, 1729.6 tps, lat 664.120 ms stddev 779.952, 0 failed
progress: 166.0 s, 2747.5 tps, lat 162.875 ms stddev 169.716, 0 failed
progress: 167.0 s, 576.6 tps, lat 221.647 ms stddev 139.452, 0 failed
progress: 168.0 s, 0.0 tps, lat 0.000 ms stddev 0.000, 0 failed
progress: 169.0 s, 611.6 tps, lat 2348.518 ms stddev 1172.552, 0 failed
progress: 170.0 s, 7502.1 tps, lat 76.586 ms stddev 171.291, 0 failed
progress: 171.0 s, 5439.7 tps, lat 86.899 ms stddev 93.895, 0 failed
progress: 172.0 s, 6552.1 tps, lat 72.686 ms stddev 96.865, 0 failed
progress: 173.0 s, 8583.1 tps, lat 35.090 ms stddev 23.118, 0 failed
progress: 174.0 s, 6612.0 tps, lat 52.980 ms stddev 254.901, 0 failed
progress: 175.0 s, 4777.0 tps, lat 194.005 ms stddev 486.784, 0 failed
progress: 176.0 s, 8702.9 tps, lat 61.529 ms stddev 50.921, 0 failed
progress: 177.0 s, 2595.1 tps, lat 180.201 ms stddev 182.923, 0 failed
progress: 178.0 s, 5601.8 tps, lat 99.164 ms stddev 165.464, 0 failed
progress: 179.0 s, 3361.1 tps, lat 137.385 ms stddev 130.730, 0 failed
progress: 180.0 s, 6017.9 tps, lat 93.904 ms stddev 88.035, 0 failed
progress: 181.0 s, 6723.8 tps, lat 75.263 ms stddev 85.029, 0 failed
progress: 182.0 s, 8314.9 tps, lat 61.824 ms stddev 62.961, 0 failed
progress: 183.0 s, 7298.2 tps, lat 70.764 ms stddev 74.236, 0 failed
progress: 184.0 s, 8742.0 tps, lat 59.424 ms stddev 62.771, 0 failed
progress: 185.0 s, 7057.0 tps, lat 73.444 ms stddev 79.784, 0 failed
progress: 186.0 s, 9451.0 tps, lat 54.219 ms stddev 29.210, 0 failed
progress: 187.0 s, 7035.0 tps, lat 71.952 ms stddev 57.469, 0 failed
progress: 188.0 s, 9033.0 tps, lat 56.227 ms stddev 48.081, 0 failed
progress: 189.0 s, 5279.9 tps, lat 92.477 ms stddev 93.549, 0 failed
progress: 190.0 s, 7388.8 tps, lat 72.826 ms stddev 114.580, 0 failed
progress: 191.0 s, 7702.5 tps, lat 66.942 ms stddev 80.070, 0 failed
progress: 192.0 s, 8686.8 tps, lat 59.188 ms stddev 47.934, 0 failed
progress: 193.0 s, 9054.3 tps, lat 57.648 ms stddev 49.698, 0 failed
progress: 194.0 s, 5106.5 tps, lat 76.760 ms stddev 135.576, 0 failed
progress: 195.0 s, 4140.0 tps, lat 144.033 ms stddev 199.357, 0 failed
progress: 196.0 s, 7862.8 tps, lat 67.789 ms stddev 57.999, 0 failed
progress: 197.0 s, 8368.2 tps, lat 62.703 ms stddev 60.593, 0 failed
progress: 198.0 s, 9336.9 tps, lat 50.719 ms stddev 48.067, 0 failed
progress: 199.0 s, 3575.9 tps, lat 152.671 ms stddev 285.610, 0 failed
progress: 200.0 s, 11952.4 tps, lat 42.545 ms stddev 41.281, 0 failed
progress: 201.0 s, 10217.0 tps, lat 48.798 ms stddev 57.456, 0 failed
progress: 202.0 s, 7444.0 tps, lat 69.777 ms stddev 113.068, 0 failed
progress: 203.0 s, 7510.8 tps, lat 69.541 ms stddev 62.895, 0 failed
progress: 204.0 s, 10154.1 tps, lat 49.703 ms stddev 34.057, 0 failed
progress: 205.0 s, 7959.1 tps, lat 50.008 ms stddev 46.910, 0 failed
progress: 206.0 s, 352.8 tps, lat 33.569 ms stddev 23.512, 0 failed
progress: 207.0 s, 0.0 tps, lat 0.000 ms stddev 0.000, 0 failed
progress: 208.0 s, 5732.5 tps, lat 283.301 ms stddev 789.629, 0 failed
progress: 209.0 s, 8322.0 tps, lat 63.444 ms stddev 81.021, 0 failed
progress: 210.0 s, 11559.0 tps, lat 43.619 ms stddev 39.940, 0 failed
progress: 211.0 s, 9755.4 tps, lat 52.761 ms stddev 83.661, 0 failed
progress: 212.0 s, 12172.0 tps, lat 42.424 ms stddev 61.887, 0 failed
progress: 213.0 s, 11779.0 tps, lat 44.569 ms stddev 43.945, 0 failed
progress: 214.0 s, 7131.5 tps, lat 65.393 ms stddev 106.124, 0 failed
progress: 215.0 s, 9007.6 tps, lat 60.965 ms stddev 122.997, 0 failed
progress: 216.0 s, 11403.6 tps, lat 44.977 ms stddev 36.038, 0 failed
progress: 217.0 s, 10711.5 tps, lat 47.578 ms stddev 38.623, 0 failed
progress: 218.0 s, 9689.0 tps, lat 52.861 ms stddev 56.425, 0 failed
progress: 219.0 s, 8435.7 tps, lat 60.111 ms stddev 58.734, 0 failed
progress: 220.0 s, 8129.3 tps, lat 63.173 ms stddev 57.507, 0 failed
progress: 221.0 s, 10326.0 tps, lat 50.463 ms stddev 48.580, 0 failed
progress: 222.0 s, 10891.0 tps, lat 46.364 ms stddev 46.177, 0 failed
progress: 223.0 s, 11274.7 tps, lat 42.816 ms stddev 51.038, 0 failed
progress: 224.0 s, 12026.2 tps, lat 45.585 ms stddev 73.108, 0 failed
progress: 225.0 s, 9144.6 tps, lat 52.630 ms stddev 37.910, 0 failed
progress: 226.0 s, 11220.6 tps, lat 47.114 ms stddev 34.526, 0 failed
progress: 227.0 s, 8483.0 tps, lat 62.395 ms stddev 86.367, 0 failed
progress: 228.0 s, 10269.8 tps, lat 49.185 ms stddev 36.233, 0 failed
progress: 229.0 s, 7412.1 tps, lat 69.977 ms stddev 54.097, 0 failed
progress: 230.0 s, 11367.1 tps, lat 44.778 ms stddev 35.319, 0 failed
progress: 231.0 s, 9939.8 tps, lat 51.776 ms stddev 62.667, 0 failed
progress: 232.0 s, 11027.2 tps, lat 46.211 ms stddev 29.350, 0 failed
progress: 233.0 s, 8123.9 tps, lat 61.566 ms stddev 51.239, 0 failed
progress: 234.0 s, 9815.1 tps, lat 53.654 ms stddev 45.409, 0 failed
progress: 235.0 s, 9261.0 tps, lat 53.618 ms stddev 41.787, 0 failed
progress: 236.0 s, 13804.0 tps, lat 36.484 ms stddev 57.090, 0 failed
progress: 237.0 s, 12884.0 tps, lat 40.679 ms stddev 65.660, 0 failed
progress: 238.0 s, 11280.0 tps, lat 42.535 ms stddev 47.761, 0 failed
progress: 239.0 s, 12313.0 tps, lat 44.936 ms stddev 96.035, 0 failed
progress: 240.0 s, 13046.0 tps, lat 38.713 ms stddev 29.844, 0 failed
progress: 241.0 s, 9885.1 tps, lat 51.074 ms stddev 58.097, 0 failed
progress: 242.0 s, 10683.9 tps, lat 48.471 ms stddev 52.766, 0 failed
progress: 243.0 s, 11713.0 tps, lat 43.424 ms stddev 50.301, 0 failed
progress: 244.0 s, 8526.1 tps, lat 39.313 ms stddev 41.309, 0 failed
progress: 245.0 s, 3239.4 tps, lat 24.656 ms stddev 22.969, 0 failed
progress: 246.0 s, 586.0 tps, lat 13.848 ms stddev 14.755, 0 failed
progress: 247.0 s, 6365.9 tps, lat 237.348 ms stddev 776.619, 0 failed
progress: 248.0 s, 6236.0 tps, lat 99.998 ms stddev 223.370, 0 failed
progress: 249.0 s, 9554.2 tps, lat 54.551 ms stddev 59.772, 0 failed
progress: 250.0 s, 11435.1 tps, lat 45.271 ms stddev 45.439, 0 failed
progress: 251.0 s, 12737.7 tps, lat 40.511 ms stddev 34.273, 0 failed
progress: 252.0 s, 13554.4 tps, lat 38.048 ms stddev 23.198, 0 failed
progress: 253.0 s, 9684.0 tps, lat 50.618 ms stddev 44.734, 0 failed
progress: 254.0 s, 11530.6 tps, lat 45.728 ms stddev 48.392, 0 failed
progress: 255.0 s, 11669.4 tps, lat 44.029 ms stddev 38.889, 0 failed
progress: 256.0 s, 12946.0 tps, lat 38.908 ms stddev 26.310, 0 failed
progress: 257.0 s, 12313.0 tps, lat 41.592 ms stddev 25.897, 0 failed
TestUser
answered 15 days ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions

Relevant content