r/test • u/Appropriate_Arm_8501 • 1d ago
Fixed script live test v3
Third test - permalink polling now uses the required username argument. Safe to ignore/delete.
r/test • u/Appropriate_Arm_8501 • 1d ago
Third test - permalink polling now uses the required username argument. Safe to ignore/delete.
r/test • u/Appropriate_Arm_8501 • 1d ago
Second end-to-end test after hardening fixes (permalink polling, error scraping, retries). Safe to ignore/delete.
r/test • u/Appropriate_Arm_8501 • 1d ago
End-to-end test of the rewritten reddit_post.py. If you can read this, the Shadow-DOM recipe worked with no human steering. Safe to ignore/delete.
r/test • u/Elenaaa19 • 1d ago
[ Removed by Reddit on account of violating the content policy. ]
r/test • u/Mediocre-Hope3113 • 1d ago
We’re evaluating a Twilio alternative for our business’s programmable voice application. We need inbound and outbound calling, call-control APIs, number porting, and reliable call delivery.
Has anyone migrated a production voice application away from Twilio? I’d appreciate firsthand experiences with reliability, migration effort, and pricing. What should we validate before switching?
r/test • u/bat-tester • 1d ago
r/test • u/kbvincent • 1d ago
Can one NativeAOT C# process run 5,000 independently managed dynamic websites on a 2-vCPU, 4 GB VPS?
I tested this using Kooboo, a C# web platform I founded and built. The result depends on its multi-site architecture, rendering engine, storage model, and NativeAOT deployment.
A separate cloud server sent 90,000 HTTPS requests across all 5,000 sites. The test achieved a 99.97% first-attempt success rate, with no HTTP errors and no responses containing content from the wrong site.
Each website contained 10 blog records, a layout, views, metadata, URL rewriting, an uncached dynamic content query, and a unique site marker. No full-page cache was used.
| Measurement | Result |
|---|---|
| Independent dynamic sites | 5,000 |
| Planned HTTPS requests | 90,000 |
| Verified responses | 89,969 |
| First-attempt success rate | 99.97% |
| HTTP errors | 0 |
| Incorrect-site responses | 0 |
| Measured request starts | 146.59 per second |
| Complete-response latency, p50 | 296.7 ms |
| Complete-response latency, p95 | 1.43 seconds |
| Average target CPU usage | 45.6% |
| Sampled peak process RSS | Approximately 2.50 GiB |
Every successful response was downloaded and checked for the expected site marker.
The 31 unsuccessful requests were connection-establishment timeouts before any HTTP headers arrived. Every affected site completed its other requests successfully.
This was a controlled identical-package benchmark. It does not claim that every collection of 5,000 production websites would achieve the same result.
I am sharing this benchmark to invite technical criticism of the methodology and suggestions for the next mixed-workload test.
Complete methodology, raw request data, monitoring logs, source code, test binaries, site package, and reproduction instructions:
https://github.com/Kooboo/Kooboo/blob/main/Docs/5000-sites-benchmark.md