Add GOMAXPROCS benchmark setup

[probelabs]

Problem / Task

The user requested a benchmark setup to demonstrate the effect of the GOMAXPROCS environment variable on Tyk Gateway performance when running with CPU limits.

Changes

• Created benchmarks/gomaxprocs/docker-compose.yml with 3 gateway services:
  1. gateway-1cpu-1gmp: 1 CPU limit, GOMAXPROCS=1
  2. gateway-2cpu-2gmp: 2 CPU limit, GOMAXPROCS=2
  3. gateway-2cpu-unset: 2 CPU limit, GOMAXPROCS unset
• Added a Redis instance and a mock upstream service (httpbin).
• Added a simple tyk.conf for the gateways.
• Added a basic API definition to test against.
• Added a README.md explaining how to run the benchmark.

Testing

• Started the environment with docker-compose up -d.
• Verified the gateways are running and serving the API.
• Verified the API proxies to the upstream service.
• Verified the GOMAXPROCS environment variable is correctly set in the containers.

[github-actions]

🚨 Jira Linter Failed

Commit: 764a6e9
Failed at: 2026-04-30 04:57:11 UTC

The Jira linter failed to validate your PR. Please check the error details below:

🔍 Click to view error details

failed to validate branch and PR title rules: branch name 'add-gomaxprocs-benchmark' must contain a valid Jira ticket ID (e.g., ABC-123)

Next Steps

• Ensure your branch name contains a valid Jira ticket ID (e.g., ABC-123)
• Verify your PR title matches the branch's Jira ticket ID
• Check that the Jira ticket exists and is accessible

---

This comment will be automatically deleted once the linter passes.

[probelabs]

This PR introduces a new benchmark setup to demonstrate the performance impact of the GOMAXPROCS environment variable on the Tyk Gateway when running with container CPU limits.

A new directory, benchmarks/gomaxprocs, is added, containing a self-contained Docker Compose environment. This setup allows for easy comparison between different gateway configurations.

Files Changed Analysis

• benchmarks/gomaxprocs/docker-compose.yml: Defines the core benchmark environment. It sets up three Tyk Gateway services with varying CPU limits and GOMAXPROCS settings, alongside a Redis instance and an httpbin mock upstream service.
• benchmarks/gomaxprocs/README.md: Provides detailed instructions on the purpose of the benchmark, how to run it, and the expected outcomes.
• benchmarks/gomaxprocs/confs/tyk.conf: A basic configuration file for the Tyk Gateway instances.
• benchmarks/gomaxprocs/apps/test-api.json: A simple, keyless API definition used for the load tests.

All files are new additions and are scoped to the benchmarks/gomaxprocs directory.

Architecture & Impact Assessment

• Accomplishment: This PR provides a reproducible environment to analyze and showcase why aligning GOMAXPROCS with the container's CPU limit is crucial for optimal performance. It directly addresses potential performance issues like CPU throttling and latency spikes caused by Go runtime and container resource misalignment.
• Technical Changes: The primary change is the addition of a Docker Compose configuration that uses the deploy.resources.limits key to restrict CPU for gateway containers, while setting the GOMAXPROCS environment variable accordingly.
• Affected Components: This change does not affect the Tyk Gateway's core application code. It adds a new, isolated benchmarking tool to the repository for development and performance analysis.

Here is a visualization of the benchmark setup:

graph TD
    subgraph "Benchmark Environment"
        LoadGenerator(Load Generator e.g., hey, k6) --> GW1
        LoadGenerator --> GW2
        LoadGenerator --> GW3

        subgraph "Docker Compose Services"
            GW1["gateway-1cpu-1gmp<br/>CPU Limit: 1<br/>GOMAXPROCS=1"] --> Upstream
            GW2["gateway-2cpu-2gmp<br/>CPU Limit: 2<br/>GOMAXPROCS=2"] --> Upstream
            GW3["gateway-2cpu-unset<br/>CPU Limit: 2<br/>GOMAXPROCS=unset"] --> Upstream

            GW1 --> Redis
            GW2 --> Redis
            GW3 --> Redis

            Redis(Redis)
            Upstream(httpbin)
        end
    end

Loading

Scope Discovery & Context Expansion

The changes are entirely self-contained within the new benchmarks/gomaxprocs/ directory. The PR has no impact on existing application code, configurations, or CI/CD pipelines. It serves as a standalone utility for performance testing and demonstration.

Metadata

• Review Effort: 1 / 5
• Primary Label: enhancement

---

Powered by Visor from Probelabs

Last updated: 2026-04-30T04:58:43.434Z | Triggered by: pr_opened | Commit: 764a6e9

💡 TIP: You can chat with Visor using /visor ask <your question>

[probelabs]

Security Issues (3)

Severity	Location	Issue
🟠 Error	benchmarks/gomaxprocs/confs/tyk.conf:3	A hardcoded secret is present in the `tyk.conf` configuration file. Hardcoding secrets is a significant security risk as they can be easily exposed through version control history. If this configuration is used as a template for production, this secret could be deployed, compromising the system. 💡 Suggestion Remove the hardcoded secret from the configuration file. Instead, load it from an environment variable. Update the `docker-compose.yml` file to pass the secret to the gateway containers via their environment.
🟡 Warning	benchmarks/gomaxprocs/confs/tyk.conf:13	The Redis database is configured with an empty password. This is an insecure default, as it would allow any service on the same network to connect to Redis without authentication. 💡 Suggestion Even for a benchmark environment, it is good practice to secure services. Configure the Redis service in `docker-compose.yml` to require a password and set that password in this configuration file, ideally by loading it from an environment variable.
🟡 Warning	benchmarks/gomaxprocs/apps/test-api.json:6	The API is configured with `"use_keyless": true`, which completely disables authentication and authorization. Any client can access the API without credentials. 💡 Suggestion This is likely intentional for a performance benchmark to eliminate authentication overhead. However, it represents a critical security risk in a production environment. It is recommended to add a prominent note in the `README.md` file for this benchmark, warning users that this configuration is insecure and should not be used for production APIs.

Architecture Issues (1)

Severity	Location	Issue
🟡 Warning	benchmarks/gomaxprocs/docker-compose.yml:9-57	The three gateway service definitions (`gateway-1cpu-1gmp`, `gateway-2cpu-2gmp`, `gateway-2cpu-unset`) contain duplicated configuration. Properties such as `image`, `volumes`, and `depends_on` are repeated across all services, which increases maintenance overhead and the risk of inconsistencies. 💡 Suggestion To improve maintainability and adhere to the DRY (Don't Repeat Yourself) principle, refactor the docker-compose file to use YAML anchors or extension fields (`x-*`). This allows you to define a common base configuration for the gateway services and extend it for each specific instance, reducing redundancy.

Performance Issues (1)

Severity	Location	Issue
🟡 Warning	benchmarks/gomaxprocs/docker-compose.yml:6-7	The `upstream` service uses the `kennethreitz/httpbin` image, which is deprecated and likely to be a performance bottleneck. This image typically runs with a single worker process, which can cap the request rate and prevent the benchmark from accurately measuring the gateway's performance under load. The results may be skewed, potentially masking the performance differences this benchmark intends to highlight. 💡 Suggestion Replace the deprecated `kennethreitz/httpbin` image with a modern, performant alternative. The official `postman/httpbin` image is a better choice, and its worker count should be increased to handle the load. Alternatively, for a very high-throughput upstream, consider a dedicated echo server like `fortio/fortio echosrv`. Example with postman/httpbin and more workers: upstream: image: postman/httpbin command: gunicorn --workers 4 --bind 0.0.0.0:80 httpbin:app

---

Powered by Visor from Probelabs

Last updated: 2026-04-30T04:58:05.108Z | Triggered by: pr_opened | Commit: 764a6e9

💡 TIP: You can chat with Visor using /visor ask <your question>

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud