Linux and NGINX tuning. Connection monitoring. Host-level flood mitigation. Argus brings them together so your team can evaluate capacity and protection on the infrastructure you already run.
Founder-led technical evaluation · Assisted deployment · Provider licensing inquiries
Start with the problem your team needs to solve. Measure the impact before making a fleet-wide commitment.
When connection limits become the bottleneck, more hardware may not be the first answer. Evaluate how tuning and connection controls affect the service you deliver.
Edge protection and origin protection solve different parts of the problem. Argus monitors host connections and applies source-based mitigation when configured thresholds are exceeded.
Linux networking and NGINX concurrency settings are evaluated against your host and workload. Measure what changes in useful throughput, errors and response times.
Socket telemetry monitors per-source connection counts against configured thresholds. Trusted sources and your traffic patterns inform the evaluation.
Source-based eBPF/XDP filtering and routing controls mitigate matching traffic. The active attachment mode and supported behavior are checked for your environment.
Whether you manage your own servers or deliver hosting to customers, start with a defined scope and a direct conversation with the developer.
A scoped engagement for one representative staging workload.
Discuss implementation on supported Linux origins after the evaluation establishes value.
Explore commercial licensing for multiple instances or a managed service offering.
Pricing is quoted for your environment, deployment size and support scope. Evaluation fees, deliverables and any ongoing license or service fees are agreed in writing before work starts.
36 measured trials on a 1-vCPU, 512-MB Linux origin, using an external load generator and a fixed 500-ms response-time budget. Three configurations, repeated runs, and the full comparison below.
At 100 requests/second, tuning plus telemetry delivered all 6,000 measured responses within the selected budget, with zero timeouts. Results depend on load: the 200-request/second trials did not establish the same advantage.
Scroll horizontally on smaller screens to see all metrics.
| Configuration | Offered RPS | Within 500 ms | Useful RPS | p95 (ms) | p99 (ms) | Request timeouts count (% sent) | Client misses |
|---|---|---|---|---|---|---|---|
| Configured reference | 50 | 99.97% | 49.98 | 319.9 | 344.5 | 0 (0.000%) | 0 |
| Tuning only | 50 | 98.27% | 49.13 | 242.4 | 701.4 | 0 (0.000%) | 0 |
| Tuning + Argus telemetry | 50 | 99.83% | 49.92 | 236.8 | 279.3 | 0 (0.000%) | 0 |
| Configured reference | 100 | 99.07% | 99.07 | 334.3 | 493.2 | 0 (0.000%) | 0 |
| Tuning only | 100 | 99.27% | 99.27 | 294.9 | 415.9 | 0 (0.000%) | 0 |
| Tuning + Argus telemetry | 100 | 100.00% | 100.00 | 246.6 | 312.1 | 0 (0.000%) | 0 |
| Configured reference | 200 | 99.67% | 199.33 | 393.7 | 457.8 | 0 (0.000%) | 0 |
| Tuning only | 200 | 95.41% | 190.82 | 447.6 | 873.0 | 5 (0.042%) | 123 |
| Tuning + Argus telemetry | 200 | 95.32% | 190.63 | 402.6 | 1367.1 | 8 (0.068%) | 232 |
“Useful RPS” counts valid HTTP 200 responses completed within 500 ms of their scheduled arrival. Percentiles cover successful responses; timeouts are listed separately. Client misses are scheduled requests the generator could not issue, not server rejection counts. The 50/100-RPS rows use a 64-active-request cap; the 200-RPS rows are the separate 128-cap validation.
At 200 requests/second, the configured reference delivered 99.67% within budget versus 95.32% for tuning + telemetry. Variation, timeouts and client limits at that load mean these tests do not establish a general capacity increase or a maximum sustainable rate.
An external Windows workstation requested the complete 33,753-byte static homepage directly from the Linux origin, bypassing Cloudflare while preserving the domain, TLS SNI and certificate validation. Requests used HTTP/1.1 keep-alive and no compression. Each trial had three seconds of warmup followed by 20 seconds of measurement, with a two-second timeout. Latency includes scheduling delay and reading the full body; its content was checked against a SHA-256 hash.
The configuration order rotated across three repeats. The initial suite tested 50, 100 and 200 requests/second. A separate nine-trial validation repeated 200 requests/second with a larger client connection allowance after the initial runs hit client limits. Both sets are included in the raw download, along with a separately labeled exploratory run.
The configured reference used 768 NGINX worker connections, somaxconn 4096 and TCP cubic. Tuning used the captured settings of 16,384 worker connections, a 65,535 worker file limit, multi_accept/epoll, somaxconn 65535 and BBR. This reference is an explicit comparison configuration, not a fresh default operating-system installation.
The Argus profile added the actual telemetry script in a dedicated test service monitoring HTTPS port 443, with a per-source threshold of 200 connections. The existing XDP filter, with an initially empty blocklist, remained attached in every configuration. These normal-traffic trials do not isolate XDP's benefit or demonstrate attack mitigation. The report documents the full setup.
It establishes observed response times at defined workloads and a concrete starting point for an evaluation. At 100 requests/second, the tuning-plus-telemetry configuration had lower pooled p95/p99 latency than the reference. At higher load, that advantage did not consistently hold. Short tests on one host and one internet path cannot establish universal savings, an SLA or a capacity multiplier, and they do not show that telemetry caused the latency improvement.
For your team, the next step is a representative application workload, longer repeated tests and an agreed latency/error budget. Deployment compatibility, persistent service operation and rollback are verified as part of the evaluation.
The earlier local-loopback and flood demonstrations are separate experiments. Their historical evidence is retained for reference and is not included in this 36-trial external comparison. Read the historical evidence log. Formatted terminal graphics are summaries rather than independent verification.
Bring your workload and your requirements. We agree on what a useful result looks like before changing anything.
Linux version, instance size, web stack, current protection and the problem you want to solve. Start on staging. Detailed configuration and access arrangements follow the scope review.
Review compatibility, existing tuning, permissions, management access and the deployment/rollback procedure. Agree on commercial terms.
Compare throughput, latency, errors and resource use. Any flood testing is separately scoped and authorized; legitimate traffic remains part of the measurement.
Review results and limitations together. Proceed to deployment or licensing only if the workload evidence and operational fit justify it.
Argus is Linux infrastructure software developed by William Denyer at Prometheus Dynamics. The commercial starting point is a scoped, founder-assisted evaluation. Assisted deployments and provider/fleet licensing are discussed based on the supported environment, results and agreed responsibilities.
The intended fit is a Linux origin running an existing reverse proxy and application. The documented demonstration uses Ubuntu 24.04 and NGINX. Your kernel, network interface, application port ownership and current controls need a compatibility review; support for every Linux distribution or hosting control panel is not assumed.
Kernel/network tuning, service configuration and filtering require privileged access. Review the affected settings, service changes and active mitigation mode before installation. An agreed change window and verified rollback are part of the evaluation scope.
The recorded demonstration preserved SSH access on ports 22 and 2222. Your management path must be verified separately. Per-source connection thresholds can affect legitimate shared-IP traffic, so trusted proxy ranges, whitelists and traffic patterns are reviewed and tested for your environment.
No. It adds controls at the Linux host. It cannot prevent traffic from saturating an upstream network link and does not replace application-layer inspection. Keep your CDN, upstream protection and application controls in the design.
Provider, fleet and managed-service licensing inquiries are welcome. Share the estimated node count, environments and whether you need internal deployment or customer-facing rights. Pricing, permitted use, updates and support obligations are agreed in the commercial terms.
Tell me what you operate and what you need to improve. We can discuss a technical evaluation, deployment quote or licensing agreement.
william@prometheusdynamics.ca ↗William Denyer
Founder & developer · Prometheus Dynamics
No access credentials needed for an initial conversation.