A practical Performance Testing note for QA Engineers: Locust for Python scripts, Go load frameworks behind Locust WebUI for heavier concurrency, and what to measure beyond green charts.
Python Locust suite · Go workers + Locust WebUI
Performance Testing is not a vanity QPS number. For API Testing under load, I care about latency distribution, error budget, saturation points, and whether the database or cache is the first wall.
Locust stays in my toolkit because it is Python-native, scriptable, and easy to keep next to API automation practice suites.
When concurrency needs to climb, I do not stay on Python alone. A Go load framework drives the workers while Locust still owns the master WebUI — same charts, hatch rate, and distributed control, with Go handling the heavy request path.
That split keeps the familiar Locust operator experience, and lets me choose the worker language by pressure and ecosystem — Python for fast scripting, Go when throughput and resource efficiency matter more.
My public Python project includes Locust, API, Selenium, and Appium examples. The Go practice repo is where I keep language-side load and tooling experiments that plug into the same Locust WebUI workflow.
When load rises, I look for:
Open for collaboration, consulting, and engineering opportunities.