Combien d'utilisateurs peuvent tenir sur un serveur à 5€

Combien d'utilisateurs peuvent tenir sur un serveur à 5€

How many users can a $5 server handle?

Title history
  • Combien d'utilisateurs peuvent tenir sur un serveur à 5€ — observed on 20261031-2252 UTC (YouTube)
🎙 cocadmin 👥 235K 📅 October 31, 2026 ⏱ 19 min 👁 18K 📄 tutorial 🧭 2026-10-31
Available in: English (current) Français

Keywords

VPSload testingGunicornNginxRedis

Summary

The video presents a hands-on experiment to determine how many concurrent users a budget VPS (4.94€/month, 1 vCPU, 4GB RAM) can support. The author sets up a Flask application served by Gunicorn with a PostgreSQL database, replicating a realistic e-commerce site with interactive features. Using the K6 load testing tool, they measure performance with the P95 latency metric and a 500ms threshold. Baseline results show 41 concurrent users. Adding more Gunicorn workers and offloading a background video to a CDN boosts this to 115 users. Introducing Nginx to serve static files brings it to 185 users. Moving all static assets to a CDN and adding Redis caching further increases the limit to 350 concurrent users, equivalent to tens of thousands of daily active users. When the database is scaled to realistic volumes (2000 products, 100k orders), capacity drops to 62 concurrent users, still a significant figure for a 5€ server.

150 words

Critical Evaluation

Value of the Information & Strength of the Argument

The information is highly empirical, derived from actual load tests using K6. The author clearly explains metrics like P95, which is more robust than mean latency, and correctly identifies bottlenecks (bandwidth saturation from a 16MB video, CPU saturation from the Python backend, database load). The argumentation is strong, systematically isolating variables (workers, static files, caching, DB volume) to show their individual impacts. The optimizations follow a logical progression and are justified by observed CPU and bandwidth usage. The only minor weakness is the use of a sponsor link for the server, but the pricing and hardware specs are disclosed, maintaining transparency. The conclusion that hundreds of concurrent users translate to tens of thousands of daily active users is a reasonable extrapolation.

Scientific Rigor, Source Quality, Title Accuracy

The methodology is rigorous: the author performs reproducible load tests and explains the reasoning behind each optimization. No external scientific sources are cited beyond the ‘concept original’ link; the content is an original study or practical tutorial. The title accurately reflects the content, directly answering the question of user capacity. The ad break for Hostinger is clearly marked and lasts approximately 120 seconds, but does not harm the overall transparency or scientific merit of the experiment.

212 words

Title / Content Match

The title perfectly matches the content, directly posing the question of user capacity on a budget server and answering it with a structured experiment.

Quality & Reliability

8/10

The methodology is empirical and reproducible, using K6 load testing with clear metrics (P95) and hardware specifications disclosed. The reasoning behind each optimization is logical and the results are presented transparently. Minor deductions for lack of external scientific sources and reliance on sponsor-provided hardware, but the practical measurements and clear explanations make the content highly reliable.

Key Moments

Cited Sources

  • Concept original de la vidéo — Lien fourni dans la description YouTube, mentionné comme l'idée originale ayant inspiré cette expérience de test de charge.

External References

Contribution & Novelties

This video provides a practical, empirical breakdown of how far a minimal cloud server can be pushed through standard DevOps optimizations. Unlike theoretical guides, it offers concrete numbers for concurrent users, CPU usage, and bandwidth at each stage, giving viewers a realistic performance baseline. The comparative analysis between a light database and a heavily loaded one (100k orders) is particularly insightful, as it quantifies the often-overlooked impact of data volume on overall application performance.

Pour aller plus loin :

  • Nginx — Reverse proxy used to offload static file serving, crucial for reducing Python application CPU load.
  • Redis — In-memory data store used for caching, effectively reducing database queries and CPU overhead.
  • Content Delivery Network — CDN solution for offloading static assets like videos and images, dramatically reducing origin server bandwidth usage.
  • Gunicorn — Python WSGI HTTP server whose worker count directly impacts concurrent request handling.
  • Grafana k6 (load testing tool) — Open-source tool used here for simulating concurrent users and measuring P95 latency (URL uncertain, but a standard tool for performance testing).

172 words

Radar Profile

The radar profile shows a strong emphasis on technical execution and practical optimization (scoring high on quantity and quality of information), while the slightly lower score on source depth reflects the hands-on nature of the content, relying on original measurements rather than citing existing academic literature.

Reliability 8/10