Budget-Ready Infrastructure Report

This is a sample capacity assessment, anonymised, of the kind Sixta produces from a 24-hour monitoring window. It is published because it answers a question most infrastructure reporting does not: not is this database healthy today, but how much growth is left before it stops being healthy, and what that costs either way.

The subject is a production Aurora MySQL writer on a db.r8g.24xlarge instance, 96 vCPU and 768 GB of RAM, engine 8.0.mysql_aurora.3.09.0. The assessment period runs from 17:19 UTC on 27 February to 04:16 UTC on 28 February 2026, across 23 monitoring runs.

Situation, complication, resolution

Situation. The instance is healthy today. CPU at 6%, connections at 3% of capacity, low risk across all 23 monitoring runs, average yield score 88.8.

Complication. The effective ceiling is only 13% above current peak. The constraint is transaction commit serialisation: 65.5% of all database load is spent waiting for Aurora storage acknowledgements. Hardware cannot fix this. The entire remaining runway is about 3,100 qps on a 96-vCPU machine that is using 6% of its CPU.

Resolution. Transaction batching, a low-risk application code change, can deliver a two- to fourfold write capacity improvement by grouping multiple inserts into a single COMMIT and amortising the storage round-trip. No database configuration or hardware change is required.

[table-1]

The gap between current peak and the user-impact threshold is 1,680 qps, a 13% increase. COMMIT alone accounts for 19.3% of total load: the application performs high-frequency single-row INSERTs, each followed by an individual COMMIT that pays the full Aurora storage acknowledgement latency.

What this means in practice

[table-2]

The critical insight is in the last two columns. Doubling the workload increases throughput by only 23% while latency rises 62%. The path from fine to failing is much shorter than the infrastructure metrics suggest, which is exactly why a dashboard showing 6% CPU is not reassurance.

Six actions, ordered by impact

[table-3]

The remainder of this report sets out the evidence and the methodology behind those findings.

The yield model: how databases fail under load

sixta-yield maps database behaviour onto a stress-strain curve borrowed from material science. Just as a metal under increasing stress passes through distinct phases before it breaks, a database under increasing concurrency follows the same pattern.

[table-4]

During this monitoring window the database oscillated between hardening, in normal operation, and plastic, during the peak hours of 21:00 to 23:00 UTC when efficiency dropped to 64–69%.

Healthy today: low risk across all 23 runs

[table-5]

Daily pattern

[table-6]

Resource utilisation at peak

[table-7]

Trend analysis

All resource trends are flat or declining across the monitoring window. No ETA to exhaustion was predicted for any resource. Throughput trend slopes ranged from −80.6 to +66.1 qps per hour with no sustained upward trajectory. On every conventional measure, this database is fine.

13% of all work is serialised, capping throughput at ~16,000 qps

What is the USL?

The Universal Scalability Law, developed by Neil Gunther, is a mathematical model predicting how system throughput changes as concurrency increases. It extends Amdahl's Law by adding a second penalty term for cross-thread coordination:

X(N) = gamma*N / (1 + alpha*(N-1) + beta*N*(N-1))

Parameters, peak period average

[table-8]

Alpha = 0.13, contention, is the dominant constraint. It represents the fraction of work that must execute serially: row locks, table locks, mutex waits, single-threaded replication, sequential transaction processing.

Beta = 0.0075, coherency, is the secondary constraint: the overhead of keeping shared state consistent across concurrent operations. This cost grows with the square of N, which is why the system eventually goes retrograde.

R-squared = 0.914 on average indicates the USL model is a good fit for this workload, explaining roughly 91% of the variance in the observed throughput-versus-concurrency data.

Doubling the workload yields 23% more output

[table-9]

The thresholds worth writing down: 20% latency increase at N = 5.9, about 40% more workload than current peak; 50% at N = 8.0, about 80% more; 100% at N = 10.9, about 2.5 times current workload, where throughput peaks. Beyond that the system is retrograde — throughput decreases as load increases, and latency spirals.

65% of database load is storage acknowledgement waits

A bottleneck diagnosis was performed using Performance Insights to identify the specific source of the contention parameter. The diagnosis queried 24 hours of PI data.

Wait event profile

[table-10]

The dominant bottleneck is wait/io/redo_log_flush at 65.5% of all database load. In Aurora MySQL this wait is the time each COMMIT spends waiting for Aurora's distributed storage layer to confirm that transaction redo records have been durably written.

Top SQL by load

[table-11]

COMMIT appearing as the second-largest contributor, at 19.3% of total load, is the key finding of the whole assessment. The commit operation costs almost as much as the row insertions themselves. That confirms the application is performing high-frequency single-row INSERTs, each followed by its own COMMIT:

BEGIN -> INSERT INTO events        -> COMMIT   (one storage round-trip)
BEGIN -> INSERT INTO user_activity -> COMMIT   (another storage round-trip)

Load is evenly distributed across roughly twenty application hosts, at about 1.8% each, with 96% of load arriving under a single database user. The bottleneck is structural to the transaction pattern, not to a specific client or a misbehaving host.

Why infrastructure knobs cannot fix this

The scaling constraint is not hardware. CPU is at 6%, memory is abundant, connections are at 3% of the limit. The constraint is serialisation inside the commit path: too many individual transaction commits, each requiring a durable write acknowledgement from Aurora's storage layer.

No Aurora-specific redo flush tuning parameter exists.
innodb_flush_log_at_trx_commit=2 does not help. In Aurora MySQL 3.x, settings 1 and 2 are functionally equivalent.
Aurora can opportunistically batch concurrent log records under 4 KB, but cannot compensate for strict single-row autocommit.
Historical Aurora binlog tuning parameters were removed in Aurora MySQL 3.x.

The solution is architectural: reduce the number of commits per unit of work.

The six actions in detail

1. Transaction batching in event ingestion

High impact, low risk. Modify the event ingestion service to batch multiple event updates into a single database transaction before committing. The current pattern, confirmed by the PI diagnosis, pays a storage round-trip per row:

BEGIN -> INSERT INTO events        -> COMMIT   -- round-trip #1
BEGIN -> INSERT INTO user_activity -> COMMIT   -- round-trip #2
BEGIN -> INSERT INTO user_activity -> COMMIT   -- round-trip #3

The recommended pattern pays one:

BEGIN
  INSERT INTO events VALUES (...), (...), (...), ...
  INSERT INTO user_activity VALUES (...), (...), ...
COMMIT                                        -- single round-trip

Start with 50 to 100 event updates per transaction. A batch size of 100 would reduce COMMIT operations by roughly 99%; the USL contention parameter would fall, raising the theoretical maximum; the effective capacity ceiling could rise two- to fourfold for writes; and the scaling profile could shift from retrograde to sublinear. The risk is low: an application-level change, no database configuration modified, fully reversible.

2. Multi-row INSERT syntax

Medium impact, low risk. Combine multiple single-row INSERT statements into multi-row INSERT syntax. This reduces round-trips for the INSERT operations themselves, which account for 22.2% of load as wait/io/table/sql/handler. Combined with transaction batching the two compound. Semantically equivalent, so the risk is low.

3. Route read-only queries to Aurora read replicas

Medium impact, low risk. The fifth and seventh SQL entries are SELECT queries consuming 5.6% of writer load. Aurora replicas share the same storage volume with under 20ms of replica lag. Routing reads away reduces writer concurrency and improves efficiency.

4. Disable binary logging if not required

Low impact, medium risk. Setting binlog_format=OFF in the cluster parameter group removes 2.1% of load, which is marginal next to transaction batching. It is a static parameter change requiring a cluster reboot, and you must first confirm no downstream system depends on the binlog.

5. Set innodb_flush_log_at_trx_commit=0

High impact, significant risk. Commits return without waiting for storage confirmation, eliminating the dominant 65.5% of database load. This is a durability trade-off: in a database crash, transactions acknowledged but not yet confirmed by storage would be lost, typically under one second of commits. Pursue transaction batching first. Consider this only as a supplementary measure — or, as a bounded experiment, as the basis of a test that measures the upper bound of what batching would achieve.

6. Consider right-sizing

Low priority. With 94% CPU headroom and an application-level serialisation bottleneck, this instance is significantly over-provisioned. After addressing transaction batching, re-assess whether a smaller instance class would suffice.

Reducing contention unlocks up to ~$109K a year

Figures below use published Aurora MySQL on-demand list prices for the db.r8g family with IO-Optimized configuration in us-east-1, as of February 2026. The current db.r8g.24xlarge lists at $14.91 an hour IO-Optimized, roughly $10,900 a month. At peak, it uses 6% of its CPU.

[table-12]

Even a conservative 20% contention reduction enables a move to db.r8g.16xlarge and about $43K a year. Full transaction batching, at 80% or better, opens the path to savings approaching $87K to $109K a year.

Inverted view: target a savings level

[table-13]

How to validate the improvement

After implementing changes, validate with the same tools that produced this assessment. A capacity claim that cannot be re-measured is not a claim, it is a hope.

[table-14]

Appendix: hourly run data

[table-15]

The 18:46 run shows an N_critical outlier of 19.6 million, caused by a near-zero beta in that run's sliding window from insufficient concurrency variation. It is marked with an asterisk rather than removed, because a model that occasionally produces a nonsense number is more trustworthy when it says so.

Questions about this sample, or about running an assessment against your own fleet: ewen@sixta.ai.

<table><thead><tr><th>Measure</th><th>Value</th></tr></thead><tbody><tr><td>Current peak</td><td>12,820 qps</td></tr><tr><td>User-impact ceiling</td><td>14,500 qps</td></tr><tr><td>Hard ceiling</td><td>~16,000 qps</td></tr><tr><td>CPU at peak</td><td>6%</td></tr></tbody></table> <table><thead><tr><th>If workload grows by…</th><th>Users experience…</th><th>System state</th></tr></thead><tbody><tr><td>+40% (to ~18,000 qps)</td><td>+20% latency — queries noticeably slower</td><td>Degrading but functional</td></tr><tr><td>+80% (to ~23,000 qps)</td><td>+50% latency — alerting thresholds hit</td><td>Significant degradation</td></tr><tr><td>2x (to ~25,600 qps)</td><td>+62% latency — serious performance issues</td><td>Approaching the wall</td></tr><tr><td>2.5x (to ~32,000 qps)</td><td>+100% latency — throughput peaks then falls</td><td>System collapse begins</td></tr></tbody></table> <table><thead><tr><th>#</th><th>Action</th><th>Impact</th><th>Risk</th><th>Requires</th></tr></thead><tbody><tr><td>1</td><td>Batch event ingestion transactions (50–100 rows per COMMIT)</td><td>High — 2–4x write scaling</td><td>Low</td><td>Application code change</td></tr><tr><td>2</td><td>Use multi-row INSERT syntax</td><td>Medium</td><td>Low</td><td>Application code change</td></tr><tr><td>3</td><td>Route read-only queries to Aurora read replicas</td><td>Medium</td><td>Low</td><td>Application routing change</td></tr><tr><td>4</td><td>Disable binary logging (if not needed)</td><td>Low</td><td>Medium</td><td>Cluster parameter and reboot</td></tr><tr><td>5</td><td>Set innodb_flush_log_at_trx_commit=0</td><td>High</td><td>Significant — durability trade-off</td><td>Cluster parameter and product decision</td></tr><tr><td>6</td><td>Right-size instance after optimisation</td><td>Up to ~$109K/yr</td><td>Low</td><td>Re-assess after changes</td></tr></tbody></table> <table><thead><tr><th>Region</th><th>Material science</th><th>Database equivalent</th><th>Detection</th></tr></thead><tbody><tr><td>Elastic</td><td>Material deforms under load but springs back fully when released</td><td>Throughput scales proportionally with concurrency, latency remains flat</td><td>USL efficiency above 90%</td></tr><tr><td>Hardening</td><td>Material resists deformation less efficiently, begins to yield</td><td>Diminishing returns: each additional concurrent query produces less throughput per unit</td><td>Efficiency 70–90%, not beyond the latency knee</td></tr><tr><td>Plastic</td><td>Permanent deformation; material will not return to its original shape</td><td>Throughput still rising but poorly, latency climbing non-linearly, system spending more time waiting than working</td><td>Efficiency below 70%, or beyond the latency knee</td></tr><tr><td>Fracture</td><td>Material breaks</td><td>Retrograde: throughput actually decreasing as concurrency increases, cascading failures</td><td>USL model predicts throughput decline at current N</td></tr></tbody></table> <table><thead><tr><th>Metric</th><th>Min</th><th>Peak</th><th>Average</th></tr></thead><tbody><tr><td>Yield score</td><td>78.8</td><td>93.0</td><td>88.8</td></tr><tr><td>Grade</td><td>B</td><td>A</td><td>A/B split (12 A, 11 B)</td></tr><tr><td>Risk level</td><td>low</td><td>low</td><td>low (all 23 runs)</td></tr><tr><td>Concurrency (N)</td><td>2.3</td><td>4.4</td><td>3.2</td></tr><tr><td>CPU</td><td>4.4%</td><td>6.0%</td><td>5.3%</td></tr><tr><td>Connections</td><td>1,164</td><td>2,144</td><td>—</td></tr><tr><td>Max connections limit</td><td>—</td><td>—</td><td>65,536</td></tr><tr><td>USL model R-squared</td><td>0.857</td><td>0.930</td><td>0.914</td></tr></tbody></table> <table><thead><tr><th>Phase</th><th>Time (UTC)</th><th>Score range</th><th>Concurrency</th><th>Region</th><th>Notes</th></tr></thead><tbody><tr><td>Active</td><td>17:00–20:00</td><td>89–92 (A)</td><td>3.0–3.5</td><td>Hardening</td><td>Normal operational load</td></tr><tr><td>Peak</td><td>21:00–23:00</td><td>79–84 (B)</td><td>3.9–4.4</td><td>Plastic</td><td>Busiest period; connections peaked at 2,144</td></tr><tr><td>Quiet</td><td>23:00–04:00</td><td>89–93 (A)</td><td>2.3–3.4</td><td>Hardening</td><td>Overnight; bottleneck shifted to balanced</td></tr></tbody></table> <table><thead><tr><th>Resource</th><th>Current</th><th>Limit</th><th>Utilisation</th><th>Headroom</th></tr></thead><tbody><tr><td>CPU</td><td>6.0%</td><td>100%</td><td>6%</td><td>94%</td></tr><tr><td>Connections</td><td>2,144</td><td>65,536</td><td>3.3%</td><td>96.7%</td></tr><tr><td>Provisioned IOPS</td><td>~11,400</td><td>Unlimited (IO-Optimized)</td><td>—</td><td>—</td></tr></tbody></table> <table><thead><tr><th>Parameter</th><th>Value</th><th>Meaning</th></tr></thead><tbody><tr><td>gamma (service rate)</td><td>4,544 qps</td><td>Ideal throughput per unit of concurrency</td></tr><tr><td>alpha (contention)</td><td>0.130</td><td>13% of work is serialised (locks, single-threaded paths)</td></tr><tr><td>beta (coherency)</td><td>0.00754</td><td>Cross-thread coordination cost; grows quadratically with N</td></tr><tr><td>N_critical</td><td>10.7</td><td>Concurrency at which throughput peaks</td></tr><tr><td>X_max</td><td>15,977 qps</td><td>Maximum achievable throughput</td></tr><tr><td>Bottleneck type</td><td>Contention</td><td>Serialisation dominates over coherency</td></tr><tr><td>Scaling profile</td><td>Retrograde</td><td>Throughput curve has a peak, then declines</td></tr></tbody></table> <table><thead><tr><th>Growth</th><th>N</th><th>Throughput</th><th>Delta</th><th>Latency</th><th>Assessment</th></tr></thead><tbody><tr><td>Current peak</td><td>4.4</td><td>12,820 qps</td><td>—</td><td>baseline</td><td>Where you are now</td></tr><tr><td>+25%</td><td>5.5</td><td>14,073 qps</td><td>+10%</td><td>+14%</td><td>Safe headroom</td></tr><tr><td>+40%</td><td>5.9</td><td>14,500 qps</td><td>+13%</td><td>+20%</td><td>Users begin to notice slower queries</td></tr><tr><td>+50%</td><td>6.6</td><td>14,919 qps</td><td>+16%</td><td>+29%</td><td>Degrading; P95 latencies climbing</td></tr><tr><td>+80%</td><td>8.0</td><td>15,464 qps</td><td>+21%</td><td>+50%</td><td>Significant; alerting thresholds hit</td></tr><tr><td>2x</td><td>8.7</td><td>15,785 qps</td><td>+23%</td><td>+62%</td><td>Serious degradation</td></tr><tr><td>2.5x</td><td>10.9</td><td>15,977 qps</td><td>+25%</td><td>+100%</td><td>The wall; throughput peaks then falls</td></tr><tr><td>3x</td><td>13.1</td><td>15,798 qps</td><td>+23%</td><td>+143%</td><td>Retrograde; adding load makes it worse</td></tr></tbody></table> <table><thead><tr><th>Rank</th><th>Wait event</th><th>Load (AAS)</th><th>% of total load</th></tr></thead><tbody><tr><td>1</td><td>wait/io/redo_log_flush</td><td>1.59</td><td>65.5%</td></tr><tr><td>2</td><td>wait/io/table/sql/handler</td><td>0.54</td><td>22.2%</td></tr><tr><td>3</td><td>CPU</td><td>0.22</td><td>8.9%</td></tr><tr><td>4</td><td>wait/synch/cond/innodb/row_lock</td><td>0.05</td><td>2.1%</td></tr><tr><td>5</td><td>wait/io/file/sql/binlog</td><td>0.05</td><td>2.1%</td></tr></tbody></table> <table><thead><tr><th>Rank</th><th>Load (AAS)</th><th>% total</th><th>SQL statement</th></tr></thead><tbody><tr><td>1</td><td>0.54</td><td>22.2%</td><td>INSERT INTO events (user_id, ...)</td></tr><tr><td>2</td><td>0.47</td><td>19.3%</td><td>COMMIT</td></tr><tr><td>3</td><td>0.41</td><td>16.8%</td><td>INSERT INTO user_activity (user_id, app_id, ...)</td></tr><tr><td>4</td><td>0.28</td><td>11.4%</td><td>INSERT INTO user_activity (user_id, app_id, ...) — variant</td></tr><tr><td>5</td><td>0.08</td><td>3.2%</td><td>SELECT Accounts.name AS ...</td></tr><tr><td>6</td><td>0.08</td><td>3.2%</td><td>INSERT INTO notifications (owner_id, ...)</td></tr><tr><td>7</td><td>0.06</td><td>2.4%</td><td>SELECT current_schema, sql_text, di...</td></tr><tr><td>8</td><td>0.05</td><td>2.2%</td><td>UPDATE users SET updated = ?, Locale...</td></tr></tbody></table> <table><thead><tr><th>Contention reduction</th><th>New throughput ceiling</th><th>Target instance</th><th>vCPU</th><th>CPU at current peak</th><th>List price (IO-Opt/mo)</th><th>Estimated savings/year</th></tr></thead><tbody><tr><td>Baseline</td><td>~16,000 qps</td><td>db.r8g.24xlarge</td><td>96</td><td>6%</td><td>$10,900</td><td>—</td></tr><tr><td>20%</td><td>~17,400 qps</td><td>db.r8g.16xlarge</td><td>64</td><td>9%</td><td>$7,300</td><td>~$43,000</td></tr><tr><td>50%</td><td>~20,200 qps</td><td>db.r8g.8xlarge</td><td>32</td><td>18%</td><td>$3,600</td><td>~$87,000</td></tr><tr><td>80%</td><td>~23,900 qps</td><td>db.r8g.4xlarge</td><td>16</td><td>36%</td><td>$1,800</td><td>~$109,000</td></tr></tbody></table> <table><thead><tr><th>To save…</th><th>Move to</th><th>Requires</th><th>Feasibility</th></tr></thead><tbody><tr><td>~$43K/year</td><td>db.r8g.16xlarge (64 vCPU)</td><td>At least 20% contention reduction</td><td>Partial batching — low-hanging fruit</td></tr><tr><td>~$87K/year</td><td>db.r8g.8xlarge (32 vCPU)</td><td>At least 50% contention reduction</td><td>Moderate batching implementation</td></tr><tr><td>~$109K/year</td><td>db.r8g.4xlarge (16 vCPU)</td><td>At least 80% contention reduction</td><td>Full batching — verify buffer pool fit</td></tr></tbody></table> <table><thead><tr><th>Metric</th><th>Source</th><th>What to look for</th></tr></thead><tbody><tr><td>io/redo_log_flush % of load</td><td>sixta-yield diagnose</td><td>Should decrease significantly</td></tr><tr><td>USL alpha (contention)</td><td>sixta-yield aws</td><td>Should decrease, raising N_critical</td></tr><tr><td>Yield score</td><td>sixta-yield aws</td><td>Should increase</td></tr><tr><td>CommitThroughput</td><td>CloudWatch</td><td>Commits per second should decrease</td></tr><tr><td>CommitLatency</td><td>CloudWatch</td><td>May increase per commit, but total commit time decreases</td></tr><tr><td>Total load (AAS)</td><td>Performance Insights</td><td>Should decrease for the same application throughput</td></tr></tbody></table> <table><thead><tr><th>Time (UTC)</th><th>Score</th><th>Grade</th><th>Region</th><th>N</th><th>Efficiency</th><th>N_critical</th><th>CPU %</th><th>Trend (qps/h)</th></tr></thead><tbody><tr><td>17:19</td><td>92.1</td><td>A</td><td>hardening</td><td>3.1</td><td>71.7%</td><td>26.2</td><td>5.4%</td><td>−39.6</td></tr><tr><td>17:46</td><td>91.9</td><td>A</td><td>hardening</td><td>3.2</td><td>70.7%</td><td>28.8</td><td>5.2%</td><td>−53.7</td></tr><tr><td>18:16</td><td>91.4</td><td>A</td><td>plastic</td><td>3.5</td><td>69.0%</td><td>20.2</td><td>5.7%</td><td>−8.4</td></tr><tr><td>18:46</td><td>92.8</td><td>A</td><td>hardening</td><td>2.9</td><td>74.6%</td><td>*</td><td>5.2%</td><td>−27.4</td></tr><tr><td>19:16</td><td>91.5</td><td>A</td><td>hardening</td><td>3.2</td><td>72.6%</td><td>14.9</td><td>5.3%</td><td>+2.6</td></tr><tr><td>19:46</td><td>90.1</td><td>A</td><td>hardening</td><td>3.3</td><td>72.2%</td><td>13.4</td><td>5.3%</td><td>+11.7</td></tr><tr><td>20:16</td><td>89.6</td><td>B</td><td>hardening</td><td>3.1</td><td>74.6%</td><td>11.8</td><td>5.5%</td><td>+42.7</td></tr><tr><td>20:46</td><td>85.5</td><td>B</td><td>hardening</td><td>3.5</td><td>71.8%</td><td>10.2</td><td>5.6%</td><td>+42.1</td></tr><tr><td>21:16</td><td>84.0</td><td>B</td><td>hardening</td><td>3.5</td><td>72.3%</td><td>9.3</td><td>5.9%</td><td>+66.1</td></tr><tr><td>21:46</td><td>78.8</td><td>B</td><td>plastic</td><td>4.2</td><td>65.6%</td><td>9.3</td><td>5.9%</td><td>+48.8</td></tr><tr><td>22:16</td><td>81.3</td><td>B</td><td>plastic</td><td>4.0</td><td>68.1%</td><td>9.6</td><td>6.0%</td><td>+37.1</td></tr><tr><td>22:46</td><td>81.1</td><td>B</td><td>plastic</td><td>4.0</td><td>68.3%</td><td>9.2</td><td>5.9%</td><td>−2.0</td></tr><tr><td>23:16</td><td>90.2</td><td>A</td><td>plastic</td><td>4.4</td><td>64.2%</td><td>77.8</td><td>5.8%</td><td>−16.2</td></tr><tr><td>23:46</td><td>89.9</td><td>B</td><td>hardening</td><td>3.4</td><td>72.2%</td><td>13.6</td><td>5.6%</td><td>−27.5</td></tr><tr><td>00:16</td><td>88.5</td><td>B</td><td>hardening</td><td>3.5</td><td>72.3%</td><td>12.3</td><td>5.8%</td><td>−9.8</td></tr><tr><td>00:46</td><td>89.3</td><td>B</td><td>hardening</td><td>3.0</td><td>77.6%</td><td>10.1</td><td>5.3%</td><td>−50.8</td></tr><tr><td>01:16</td><td>89.0</td><td>B</td><td>hardening</td><td>2.8</td><td>79.7%</td><td>9.0</td><td>5.1%</td><td>−57.6</td></tr><tr><td>01:46</td><td>90.0</td><td>A</td><td>hardening</td><td>2.6</td><td>82.4%</td><td>8.5</td><td>4.9%</td><td>−80.6</td></tr><tr><td>02:16</td><td>90.6</td><td>A</td><td>hardening</td><td>2.4</td><td>84.8%</td><td>7.8</td><td>4.8%</td><td>−44.9</td></tr><tr><td>02:46</td><td>90.5</td><td>A</td><td>hardening</td><td>2.4</td><td>84.8%</td><td>7.6</td><td>4.5%</td><td>−77.1</td></tr><tr><td>03:16</td><td>89.4</td><td>B</td><td>hardening</td><td>2.5</td><td>82.5%</td><td>7.9</td><td>4.4%</td><td>−52.5</td></tr><tr><td>03:46</td><td>93.0</td><td>A</td><td>hardening</td><td>2.3</td><td>84.1%</td><td>9.0</td><td>4.4%</td><td>−51.1</td></tr><tr><td>04:16</td><td>91.7</td><td>A</td><td>hardening</td><td>2.5</td><td>80.5%</td><td>9.7</td><td>4.7%</td><td>−19.8</td></tr></tbody></table>

Subjects

Cost and business impact