How Are You Approaching Load Testing in Your Projects?

I’m currently laying the groundwork for a proper load testing strategy at my company and would love to hear how others are handling this.

Which load testing tools are you actively using?

Do you prefer a CLI-based workflow or something more GUI-driven?

Are you using any paid tools, and have they proven worth the investment?

Is load testing automated or CI-integrated in your setup?

How close does your simulated traffic get to real user behavior?

Any interesting or emerging tools/approaches you’ve experimented with?

Would really appreciate insights from your hands-on experiences!

Been working in performance engineering for nearly 7 years now, so I’ve seen tools come and go.

“JMeter with Custom CI Scripts”

We rely on load testing with Apache JMeter at my current company. It might not be the most hyped tool in 2025, but it’s still incredibly solid and gives us full control. We execute it through CLI mode within GitHub Actions, and we’ve wrapped the whole setup in Dockerized custom scripts. These tests feed metrics into InfluxDB and Grafana dashboards.

It wasn’t plug-and-play—we spent time creating reusable logic using CSV datasets, timers, and scripting inside JMeter to reflect real user behavior. For newcomers, I often suggest trying Taurus too; it puts a nice wrapper around JMeter if you want faster iteration without losing power.

If you’re okay investing setup time and value flexibility, JMeter remains a dependable choice for load testing workflows.

Coming from a more agile product background, I always look for lightweight, integrated options.

“Artillery + Playwright Hybrid for API + UX Testing”

Building on @tim-khorev’s point about real-world usage patterns, we’ve taken a hybrid route for load testing by combining Artillery for API-level stress and Playwright to observe UI responsiveness under pressure.

Artillery’s YAML+JS setup makes scripting intuitive, especially for simulating user journeys—not just API endpoints. For example, we model a complete session: login → browse → checkout, instead of isolated API calls. These tests are tied into our GitLab CI—quick runs on every merge, and deeper load tests every night.

We also explored enterprise tools but found that Artillery + Playwright gave us enough flexibility to replicate event-driven usage without needing a license. If your system has user sessions or real-time interactions, this blend works surprisingly well for load testing that covers both frontend and backend insights.

Having led QA efforts in scale-up environments, I’ve learned that simplicity and developer buy-in are key.

“Using k6 OSS + Gradual Cloud Transition”

@dimplesaini.230 approach reminds me of our journey—except we landed on load testing with k6. We started with the open-source version, and what stood out was the developer-friendly design. Writing tests in JavaScript made it easier to get the whole team involved, and our scripts now live alongside the application code in Bitbucket.

We use thresholds, parameterized data, and iterations to reflect end-user behavior. Recently, we’ve begun migrating larger tests to k6 Cloud. The OSS version handled CI (Bitbucket Pipelines) just fine, but cloud helped scale tests for pre-production scenarios and gave us trend visibility.

What I appreciate is that k6 makes load testing feel like code—not some separate QA ritual. It grows with your team, from local runs to cloud-scale stress.