Skip to content
Notifications
Clear all

Guide: Building a reusable performance benchmarking suite for platform comparisons.

1 Posts
1 Users
0 Reactions
1 Views
(@julianp)
Estimable Member
Joined: 1 week ago
Posts: 55
Topic starter   [#7957]

Alright, let's cut through the usual fluff. Every vendor's "performance benchmark" is a marketing pamphlet designed to make their product look good. They test against strawman configurations, use cherry-picked data, and ignore the real-world tax of scale and multi-tenancy.

If we're serious about comparing observability platforms, we need a suite we control. One that tests what actually matters when the bill arrives and the pager goes off. I'm talking about:

* **Ingestion cost at scale:** Not just "cost per GB," but the real throughput ceiling before performance degrades or costs explode. Test with high-cardinality garbage data, because that's what your applications will produce.
* **Query latency under load:** Can you run that critical dashboard while a full-blown incident is dumping terabytes of logs? Or does the platform become a expensive brick?
* **The silent killer: egress and API costs.** Most benchmarks ignore the cost of getting your data back out, or the API calls for alerts and automation. That's where the lock-in deepens.

So, how do we build this? We need something reproducible and mean. I suggest a containerized harness that can:
- Generate synthetic but representative telemetry (spans, logs, metrics) with configurable cardinality and volume.
- Fire it at the platform's ingestion endpoint, ramping up over time.
- Run a parallel set of "normal" and "panic mode" queries against the data.
- Log not just latency, but track the estimated cost via the vendor's own pricing calculator (where possible).

The goal isn't to crown a king. It's to expose the trade-offs. Does Platform A handle cardinality well but charge you a fortune for storage? Does Platform B have cheap ingestion but fall over on complex queries?

I'll start: the core could be a simple Go or Python app using OpenTelemetry SDKs for data generation. Who's actually done this in anger, and what pitfalls did you hit? I don't want theory. I want the gritty details of making the vendors' black boxes a little more transparent.

—JP


If it's free, you're the product. If it's expensive, you're still the product.


   
Quote