Tool/k6 load testing

[josecmu27]

k6 Load Testing Tool Integration

Summary

This PR integrates k6 as a dynamic analysis tool for load testing the NodeBB application. k6 simulates multiple concurrent users hitting key endpoints to measure performance and identify bottlenecks under stress.

---

Evidence of Installation

• Created k6/README.md with installation instructions (brew install k6)
• Created k6/load-test.js test script
• Created k6/output.txt containing terminal output from a full test run

---

Test Results

The test ramped up from 10 to 50 virtual users across ~3.5 minutes, hitting 4 key endpoints:

• / (Homepage)
• /categories
• /recent
• /api/categories

checks_total.......: 11952   45.684351/s
checks_succeeded...: 99.98%  11950 out of 11952
checks_failed......: 0.01%   2 out of 11952

✓ homepage status is 200
✗ homepage loads in <2s
  ↳  99% — ✓ 1327 / ✗ 1
✓ categories status is 200
✓ categories loads in <2s
✓ recent topics status is 200
✗ recent topics loads in <2s
  ↳  99% — ✓ 1327 / ✗ 1
✓ API status is 200
✓ API responds in <1s
✓ API returns JSON

Overall success rate of 99.98% across ~12,000 checks. The 2 failures were occasional response time spikes on the homepage and recent topics page under peak load (50 concurrent users), which is a meaningful finding about the system's performance ceiling.

---

Pros

• Easy to set up — standalone binary with minimal configuration needed
• Readable scripting — test scripts are written in plain JavaScript, making them easy to write and maintain
• Detailed metrics — provides response times, error rates, percentiles (p95), and custom thresholds out of the box
• Realistic load simulation — supports staged ramp-up/ramp-down to mimic real traffic patterns
• Clear pass/fail thresholds — can be configured to fail CI pipelines if performance degrades
• No interference with existing mocha/ESLint tooling

Cons

• Not an npm package — requires a separate binary installation, which complicates CI/CD integration compared to npm-based tools
• No browser simulation — tests HTTP endpoints only; doesn't simulate real browser behavior (JS rendering, assets, etc.)
• Requires a live server — cannot be run without a running NodeBB instance, making it harder to integrate into standard unit test pipelines
• Limited to black-box testing — only observes external behavior, gives no insight into internal code paths or memory usage
• Threshold tuning required — default thresholds need manual calibration per project to be meaningful

---

Customization Notes

• A priori: The BASE_URL must be updated to point to the live NodeBB instance before running. Thresholds (e.g. p(95)<2000) should be tuned based on expected traffic.
• Over time: As new endpoints are added to NodeBB, the test script should be expanded to cover them. Thresholds may need tightening as the system matures.

[josecmu27]

Tool Evaluation: k6

What is the name and high-level description of what the tool does?
k6 is an open-source load testing tool that simulates multiple concurrent users sending HTTP requests to a web application. It measures response times, error rates, and throughput to evaluate how a system performs under stress.

Is the tool used for static or dynamic analysis?
k6 is a dynamic analysis tool, it requires a live running instance of the application to run tests against.

What types of problems does this particular tool catch?
This tool catches the following problems:

• Slow endpoints that exceed acceptable response time thresholds under load
• Endpoints that fail or return errors under concurrent traffic
• Performance bottlenecks that only appear at scale, for example our homepage and recent topics page occasionally exceeded 2s under 50 concurrent users.

What types of customization are possible or necessary?

• A priori: BASE_URL must be set to the live NodeBB instance before running. Response time thresholds need to be tuned to realistic expectations for the project.
• Over time: New endpoints should be added to the test script as the app grows. Load stages (number of virtual users, ramp-up duration) can be adjusted to simulate different traffic scenarios. Custom metrics can be added to track specific behaviors.

How can/should this tool be integrated into a development process?
k6 is best run as part of a pre-release or staging pipeline rather than on every commit, since it requires a live server and takes several minutes to run. It can be integrated into GitHub Actions to automatically run against a staging deployment and fail the pipeline if thresholds are exceeded.

Are there many false positives? False negatives? True positive reports about things you don't care about?

• False positives: Low — threshold failures are usually genuine performance issues. Occasional spikes (like our 2 failures out of 11,952 checks) can be false positives caused by network jitter rather than real app problems.
• False negatives: Possible — k6 only tests endpoints you explicitly define, so untested endpoints may have hidden performance issues.
• True positives you don't care about: Minor response time spikes under extreme load (e.g. 50 concurrent users) may not be relevant if your app realistically expects far fewer users.