1. Contexte général
Voilà l’architecture technique du forum Discourse hébergé à domicile, sur une stack solide, propre, et étonnamment musclée pour un usage perso.
Il inclut une estimation du nombre d’utilisateurs simultanés supportables.
2. Vue d’ensemble de l’infrastructure
2.1 Accès Internet – Freebox Ultra
-
Fibre 8 Gbit/s down / 8 Gbit/s up
-
IP publique fixe
-
NAT vers le NAS Synology
Traduction :
Oui, 8 Gbit/s c’est beaucoup, c’est plus de bande passante que 90 % des PME françaises.
Et non, ce n’est pas une invitation à lancer Gatling, JMeter ou k6 “pour voir”. 
2.2 Infrastructure locale – NAS Synology DVA3221
-
DSM 7.2.2-72806 Update 5
-
12 CPU, 32 Go RAM
-
Carte réseau 10GbE
-
Héberge :
- Reverse proxy
- Certificat Let’s Encrypt
- VM Debian via VMM
2.3 Virtualisation – VM Debian 13.2
-
6 vCPU
-
16 Go RAM
-
Discourse installé via Docker
3. Architecture réseau
-
DNS OVH → IP Freebox
-
Freebox → NAT → NAS
-
NAS → Reverse proxy + TLS
-
NAS → VM Debian
-
VM → Container Discourse
-
Nginx interne → Unicorn → Rails → PostgreSQL / Redis
-
Réponse → retour vers l’utilisateur
4. Architecture interne de Discourse
4.1 Composants
| Composant | Rôle |
|---|---|
| Nginx interne | Reverse proxy interne, assets |
| Unicorn | Serveur d’application Ruby |
| Ruby on Rails | API + logique métier |
| PostgreSQL | Base de données |
| Redis | Cache + file de jobs |
| Sidekiq | Tâches asynchrones |
| Ember.js | Front dynamique |
5. Analyse technique des paramètres
5.1 PostgreSQL
db_shared_buffers: 4GB
- C’est très confortable pour une base de forum.
- Permet de garder énormément de pages en mémoire.
- Réduit drastiquement les lectures disque.
- Idéal pour absorber des pics de lecture (topics populaires, pages vues en masse).
db_work_mem: 40MB
- Très généreux pour les tris, les jointures, les indexations.
- Améliore les performances des recherches et des pages complexes.
5.2 Redis
redis_cache_size: 768mb
- Excellent pour Discourse.
- Permet de garder beaucoup de sessions, de caches de pages, de fragments HTML.
- Réduit la charge sur PostgreSQL.
5.3 Unicorn
UNICORN_WORKERS: 4
- 4 workers Ruby = 4 requêtes simultanées réellement traitées.
- Avec 6 vCPU, c’est un bon ratio.
- Le front Ember.js + le cache Redis limitent la pression sur Unicorn.
5.4 Sidekiq
DISCOURSE_SIDEKIQ_WORKERS: 3
Très bon pour absorber :
- Envoi d’emails.
- Notifications.
- Indexation.
- Tâches de maintenance.
- Évite que Sidekiq devienne un goulot d’étranglement.
6. Estimation du nombre d’utilisateurs simultanés
Objectif :
Combien d’utilisateurs simultanés l’architecture peut supporter.
6.1 Capacité théorique (technique pure)
Avec :
-
6 vCPU dédiés à Discourse
-
16 Go de RAM
-
PostgreSQL local
-
Redis local
-
Unicorn (multi‑workers)
-
Fibre 8 Gbit/s symétrique
-
Stockage rapide du NAS
On peut raisonnablement estimer :
Entre 500 à 900 utilisateurs simultanés actifs
(= utilisateurs en train de charger des pages, scroller, poster, liker)
Et même :
1 500 à 3 000 utilisateurs connectés
(= sessions ouvertes mais activité faible)
Pourquoi ?
-
Redis a de la marge.
-
Discourse est très optimisé côté cache (Redis + CDN interne).
-
Unicorn peut gérer plusieurs workers Ruby en parallèle.
-
PostgreSQL sur 6 vCPU / 16 Go RAM est très confortable.
-
Le réseau 8 Gbit/s ne sera jamais le bottleneck.
-
Le NAS Synology est largement assez puissant pour servir de reverse proxy.
7. Conclusion
8. Conclusion
L’architecture est robuste, propre, bien segmentée, et largement suffisante pour un forum de passionnés de performance.
Rappel officiel :
Merci de ne pas lancer de tests de performance sur cette plateforme.
Pas même “juste un petit test pour voir”.
Pas même “en off-peak”.
Pas même “promis je mets que 50 utilisateurs virtuels”.
Mes filles veulent regarder Netflix.
Mon fils veut jouer a Roblox.
Et moi, je veux dormir tranquille 