Test-driven optimization
Continuous performance testing and tuning
for any stack
Application-aware.
Autonomous.
AI-powered.
Akamas Studio uses machine learning, your own performance tests and the goals you set to find the best full-stack configuration, before anything reaches production.
−50%
Kubernetes application cost
Sabre, tuning JVM memory, garbage collection and pod resources for its Java microservices during the move to cloud-native.
+23%
Peak transaction volume
lastminute.com, on its key Java microservices application, in less than two weeks.
2.5x
Throughput, same pod
A Java service on Kubernetes, after one day of automated experiments, with response time down from 7.5 s to 350 ms.
1.5x
Transaction throughput
A major European digital payment processor, after twenty hours of automated tuning, with 20% less compute per transaction.
When to use it
Some configurations can only be proven under load
Akamas Studio runs your own performance tests against candidate configurations, learns from every result and keeps only what the measurements prove. Our engineers work with you to scope the parameters and the goal in Studio.
Peak readiness
Migrations
Releases
New architectures
Beyond Kubernetes
AI inference
How it works
How does Akamas Studio find the best configuration?
-
Scope the study in Studio
Define the tunable parameters, the goal and the constraints for your stack, together with our engineers. Studio drives the load testing tools you already use and reads results from your APM and observability stack. -
Studio tests, learns and iterates
Each candidate configuration runs against your own performance test. The optimizer scores it against the goal and the constraints, then uses what it learned to choose the next one. -
Validate and promote the winner
Studio applies each configuration through your configuration management and measures it. The best one, proven under your load, goes to your team for review and to production through your pipeline.
Full-stack
What can Akamas Studio optimize?
Any stack with tunable parameters: Java heap and garbage collection, Spark executors, Kafka consumers, the Go, Node.js and .NET runtimes, KubeVirt VM resources, EC2, GCE and Azure VMs, PostgreSQL and MongoDB, and vLLM inference servers. Your custom tech counts too.
Parameters interact. A heap size that suits one garbage collector hurts another. Studio tunes them together, so it doesn’t fix one layer by breaking the next.
Browse the optimization packs Browse the optimization packs
Goal-oriented
How do you tell Studio what better means?
You set the goal, such as maximum throughput or minimum cloud cost, and the constraints it must respect, such as a latency ceiling or a minimum transaction rate.
Studio scores every test against both. A configuration that breaks a constraint never wins, however good its score.
Safe by design
Why test configurations before production?
Some effects only show up under load: garbage collection pauses at peak, a thread pool that saturates, a CPU limit that throttles. Studio finds them in your test environment, where a bad configuration costs a test run, not an incident.
Nothing Studio tries touches production. Only the configuration the measurements prove reaches your pipeline.
Automated
Can a study run on its own?
Yes. Studio runs the load test, collects the metrics, applies the next configuration and starts again, for hundreds of iterations, day and night. Studio works with the load testing, observability and configuration management tools you already use.
When the study ends, your team reviews the winning configuration and your CI/CD pipeline promotes it, by hand or automatically.
How it compares
How is Akamas Studio different from manual performance tuning?
A load test tells you how a configuration performs. It doesn’t tell you which configuration to try next.
| Manual tuning | Load testing alone | Akamas Studio | |
|---|---|---|---|
| Who picks the next configuration | An engineer, from experience | An engineer, after reading the report | The optimizer, from every result so far |
| Configurations tried | A handful | A handful, measured better | Hundreds per study, day and night |
| Parameters tuned together | One or two at a time | One or two at a time | Across the stack, including how they interact |
| Goals and SLOs | Informal | Pass or fail thresholds | An explicit goal, with hard constraints |
| What reaches production | The last configuration that seemed fine | The configuration that passed the test | The best configuration found, with the evidence behind it |
Proof
What results do teams get with Akamas Studio?
Four customers, four published case studies.
- Operating cost
- −20%
- Search response time
- −27% under load
- Stack
- Java microservices on Kubernetes
Travel technology
Sabre halved Kubernetes application cost in its cloud-native migration
The migration had to be fast and invisible to customers. Studio found the best JVM memory sizing, garbage collector and pod CPU and memory for its Java microservices, and optimization itself ran 4 to 6 times faster.
Read the Sabre case study Read the Sabre case studyTravel and expense
Navan found the AWS configuration for lower cost and higher load
Studio identified the EC2 and JVM configuration that reduces cloud cost and supports expected traffic growth, within SLOs and resource utilization policies. The team also used it to validate its migration plans to AWS Fargate.
Read the Navan case study Read the Navan case studyBusiness software
TeamSystem lowered cloud cost without lowering service quality
Hundreds of microservices on Kubernetes, on Azure and AWS, with frequent releases driven by new legislation. Studio identified the optimal JVM and Kubernetes parameters for the most critical ones, cutting cloud cost and carbon footprint.
Read the TeamSystem case study Read the TeamSystem case studyAkamas Vivo
Running Kubernetes in production?
Akamas Vivo reads the metrics your observability stack already collects and recommends pod, runtime and node group settings, with no test environment needed. Much of what it knows comes from studies like these.
