j6 is an experimental HTTP performance testing tool written in Go.
The current scaffold provides a Cobra-powered CLI, named test profiles, concurrent HTTP execution, basic metric aggregation, and a clean terminal summary branded as J6 Tester. It is intentionally small so the core mechanics stay easy to understand as the project grows.
Pre-alpha runnable scaffold.
Current state:
- Cobra CLI with friendly commands.
- Built-in performance profiles:
load,stress,spike, andsoak. smokeprofile for quick sanity checks.- Concurrent HTTP request execution with virtual users.
- Basic metrics: total requests, failures, status codes, errors, latency, and throughput.
- Terminal summary reporting.
The long-term goal is to provide a small, understandable performance testing tool for HTTP services.
Planned capabilities may include:
- Configuring target endpoints and request scenarios.
- Exporting structured reports such as JSON or CSV.
- Supporting progressively richer scenarios without hiding the core mechanics.
.
├── cmd/
│ └── j6/
│ └── main.go
├── docs/
│ └── .gitkeep
├── internal/
│ ├── cli/
│ ├── config/
│ ├── engine/
│ ├── httpclient/
│ ├── metrics/
│ ├── reporter/
│ ├── scenario/
│ └── scheduler/
├── testdata/
│ └── .gitkeep
├── .gitignore
├── go.mod
└── README.md
Executable entrypoint for the j6 binary.
This package stays focused on startup and process exit behavior.
Cobra command definitions, flags, examples, and command-to-runtime wiring.
Configuration loading, defaults, and validation.
This package defines test profiles, normalized runtime settings, and validation.
Scenario modeling.
This package defines what is being tested: target URL, method, headers, and request body.
Work scheduling.
This package decides when requests are issued and currently supports fixed virtual-user concurrency with optional per-VU request pacing.
HTTP execution.
This package wraps Go's net/http package and handles request execution, timeout behavior, response body draining, and timing.
Metric collection and aggregation.
This package tracks request counts, failures, status codes, error messages, latency statistics, and throughput.
Result output.
This package formats terminal output. Structured exports such as JSON or CSV can be added here later.
Top-level orchestration.
This package connects configuration, scenarios, scheduling, HTTP execution, and metrics into a complete test run.
Run a load test:
go run ./cmd/j6 load https://example.comRun the four core performance test types:
go run ./cmd/j6 load https://example.com
go run ./cmd/j6 stress https://example.com
go run ./cmd/j6 spike https://example.com
go run ./cmd/j6 soak https://example.comRun a quick smoke check:
go run ./cmd/j6 smoke https://example.com --duration 5sOverride defaults:
go run ./cmd/j6 stress https://example.com \
--vus 100 \
--duration 1m \
--timeout 5s \
--header 'Authorization: Bearer token'Use the generic run command:
go run ./cmd/j6 run spike https://example.com/search --method POST --body '{"q":"books"}'Design notes, architectural decisions, experiments, diagrams, and longer-form project documentation.
Fixtures for tests, sample configuration files, mock responses, and example scenarios.
The project is expected to grow in small, reviewable increments.
-
Rate control
- Add scheduled request dispatch.
- Explore ticker-based pacing.
- Define behavior when the target is slower than the configured rate.
-
Richer scenarios
- Support HTTP methods, headers, and bodies.
- Support multiple endpoints.
- Add weighted requests after the simple model is reliable.
-
Reporting
- Add JSON output.
- Add CSV output.
-
Tests
- Use
httptest.Serverfor HTTP behavior. - Run the race detector once concurrency is introduced.
- Use
Performance testing tools can produce misleading results if their measurement model is unclear. The following questions should be answered as the implementation evolves:
- Is latency measured entirely from the client side?
- Are DNS lookup, TCP connection setup, and TLS negotiation included?
- Are failed requests included in latency statistics?
- How are timeouts represented in reports?
- What happens when requests take longer than the configured pacing interval?
- Does the tool target active concurrency or request arrival rate?
- Are response bodies read, discarded, streamed, or preserved?
- How are metrics synchronized under concurrency?
- Does cancellation stop new work only, or does it also interrupt in-flight requests?
- Are percentiles exact or approximate?
- Are warm-up requests included in final results?
Run the current scaffold:
go run ./cmd/j6Build the binary:
go build -o bin/j6 ./cmd/j6Run tests:
go test ./...Run tests with the race detector:
go test -race ./...Format code:
gofmt -w .The module currently uses the local name:
j6
If the project is published, this should be changed to a full import path, for example:
github.com/<owner>/j6
The current scaffold does not include:
- A CLI framework.
- A configuration file format.
- A load-generation engine.
- HTTP request execution.
- Metrics aggregation.
- Report formatting.
- Tests.
- External dependencies.
These omissions are intentional for the initial project foundation.
No license has been added yet.