# Tpc H Tpc C Energy Eval

> Evaluates the energy efficiency and performance trade-offs of a distributed database cluster versus a single high-end server under OLAP and OLTP workloads. It probes the system's ability to maintain energy proportionality through dynamic node scaling and measures the overhead incurred during data migration and cluster reconfiguration. Use when the user wants to benchmark on TPC-H, TPC-C, or asks about evaluating this task. Reports energy consumption per query.

- Skill: `qhjqhj00/tpc-h-tpc-c-energy-eval` (Agent Skill)
- Install (CLI): `npx skillmds add qhjqhj00/tpc-h-tpc-c-energy-eval`
- Raw SKILL.md: https://api.skillmd.com/api/skills/qhjqhj00/tpc-h-tpc-c-energy-eval/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: qhjqhj00 (https://skillmd.com/u/qhjqhj00)
- Updated: 2026-09-08
- Page: https://skillmd.com/skills/qhjqhj00/tpc-h-tpc-c-energy-eval

---


# tpc-h-tpc-c-energy-eval

> Energy and Performance-Can a Wimpy-Node Cluster Challenge a Brawny Server? — Daniel Schall, Theo Harder (2014) (arXiv:1407.0386, 2014)

## What this evaluates

Evaluates the energy efficiency and performance trade-offs of a distributed database cluster versus a single high-end server under OLAP and OLTP workloads. It probes the system's ability to maintain energy proportionality through dynamic node scaling and measures the overhead incurred during data migration and cluster reconfiguration.

## Datasets

- **TPC-H** — total 300; splits: test (-1)
- **TPC-C** — total 1000; splits: test (-1)

## Metrics

- `energy consumption per query` **(primary)** — range: mJoule/query
  - Total energy consumed by the system (in Joules or milliJoules) divided by the total number of queries processed during the measurement window.
- `query response time` — range: seconds
  - The elapsed time between query submission by the benchmark driver and the delivery of the result to the client.

## Input / output format

**Input**: TPC-H and TPC-C benchmark queries submitted by a configurable number of parallel client processes at specified time intervals.

**Output**: Query results, per-query response times, and continuous power/energy readings from a hardware measurement device.

## Scoring recipe

```python
def compute_metrics(energy_readings, query_timestamps):
    total_energy = sum(energy_readings)
    total_queries = len(query_timestamps)
    energy_per_query = total_energy / total_queries
    response_times = [t_end - t_start for t_start, t_end in query_timestamps]
    return energy_per_query, response_times
```

## Common pitfalls

- Focusing solely on peak throughput or raw speed while ignoring energy proportionality at moderate utilization levels.
- Overlooking the severe latency penalty (up to 20 minutes) caused by dynamic data migration when evaluating cluster elasticity without forecasting.
- Comparing a statically powered server against a dynamically scaled cluster without accounting for the server's idle power waste.

## Evidence (verbatim from paper)

> Comparing energy consumption per query of both systems, the cluster delivers far better results for average utilizations. Due to the cluster's scale-out and adaptation to the necessary number of nodes, its energy consumption per query stays at the same level almost the entire time, regardless of utilization.

## Citation

```bibtex
@misc{schall2014energy,
  title={Energy and Performance-Can a Wimpy-Node Cluster Challenge a Brawny Server?},
  author={Daniel Schall, Theo Harder (2014)},
  year={2014},
  note={arXiv:1407.0386}
}
```

- arXiv: 1407.0386