Hey folks, been lurking for a while but finally have something worth sharing! As someone who’s neck-deep in building event-driven data pipelines, cold starts are my eternal nemesis. We've been evaluating OpenClaw for a new stream processing layer that handles bursty analytics traffic, and everyone knows their marketing docs promise "sub-second cold starts." But, as we all learned the hard way, reality often has other plans.
So, we decided to run a proper production-scale load test. The setup:
- **Function:** Python 3.11, using the OpenClaw SDK to transform JSON events and push to our data lake.
- **Memory:** 2048 MB (their recommended "balanced" tier).
- **Architecture:** HTTP-triggered, deployed via their container registry.
- **Test Pattern:** 12 hours of no traffic (forcing a complete freeze), followed by a sudden burst of 100 concurrent requests. We repeated this three times across different days.
Here are the actual **p99 latency numbers** we captured for that first request in the burst:
```plaintext
Test Run 1: 4.72 seconds
Test Run 2: 5.11 seconds
Test Run 3: 4.89 seconds
```
Yes, you're reading that right — we're looking at **~5 seconds** for a true cold start, not sub-second. The warm performance is great (around 120ms p99), but that initial spike is a killer for user-facing APIs or real-time dashboards.
Some observations that might help others:
* The provision time (getting a container ready) seemed to be the biggest chunk, often over 3 seconds.
* Increasing memory to 4096 MB shaved off about 0.8 seconds, but the cost increase wasn't justifiable for our use case.
* Their "pre-warmed instances" feature (an extra $$$ tier) did bring the first request down to ~1.5 seconds, but that's still not what they advertise for the standard tier.
Has anyone else done similar benchmarking with OpenClaw, especially with the newer "SnapStart" equivalent they're beta testing? I'm curious if our experience is the norm or if we have a misconfigured VPC or dependency loading issue. Also, for batch-oriented ETL jobs, this might be a non-issue, but for anything requiring low-latency responses, it's a significant hurdle.
What strategies have you all used to mitigate this on OpenClaw? Some ideas we're exploring:
* A lightweight cron job to "ping" the function every 5 minutes (feels hacky and wastes invocations).
* Moving the core logic to a step function with a constant warm container (but adds complexity).
* Just accepting the cold start and designing our frontend to handle a loading state for certain operations.
Really hoping to start a detailed discussion on real-world performance trade-offs with these managed services. The devil is always in the details, isn't it?
Data nerd out
Data nerd out