Capacité du serveur

Mis à jour le 30/05/2026 · après le déploiement des correctifs 6.61–6.64.

L’essentiel : préproduction, aucun héritage

Il n’y a pas encore de vrais utilisateurs sur le serveur de production. Toutes les installations sont des installations de test. D’où :

$MIN in version_check.php vaut désormais $CURRENT (=6.66). Toute version antérieure est forcée vers la version courante.
La migration naturelle par la boîte de dialogue de mise à jour est une stratégie de production. Pour l’instant, déployer signifie simplement relever $MIN.
Les couches de rétrocompatibilité au cas où un ancien client sont inutiles — un tel client n’existe pas.

Estimations par palier de charge

Audience, MAU	WS simultanés (pic)	État d’un seul VPS	Principal goulet d’étranglement
≤ 30k	≤ 3k	Dix fois de marge, au repos	Rien dans notre pile
30k — 100k	3k — 10k	Le palier cible, confortable	Le processeur de Workerman encaisse sans peine les pongs et les événements. La base travaille sur clés primaires. 500 Mo–1 Go de RAM pour les sockets.
100k — 200k	10k — 20k	Fonctionnement à la limite	L’unique processus Workerman surchauffe au pic. Qu’un bug de WebSockets coupés apparaisse et la dégradation commence.
> 200k	> 20k	On touche le plafond	La phase C devient nécessaire (Workerman count=4 plus Redis pub/sub pour un `$hosts`/`$guests`).

Ce qui a été corrigé en 6.61–6.64

Metric	Avant les correctifs	Après la 6.64	Où c’est fait
`ble_token_renew` en file d’attente tant que le propriétaire est hors ligne	1300 en 4 h	1 (déduplication par UNIQUE INDEX)	Server — fonctionne avec n’importe quel client
Reprises HTTP en cas de panne réseau	5 clés × 1/min = 7200 par jour	~50 par jour (attente de 30 minutes)	Client 6.64 — un nouvel APK est nécessaire
Reconnexions WebSocket sur un réseau instable	~10/min (reprise à 1 s)	~1/min (attente de 60 s)	Client 6.62+ — un nouvel APK est nécessaire
Requêtes en base sur hello pendant l’instabilité WebSocket	~50/s sur 10 000 clients	~5/s	Server — la limite de 5 secondes protège de n’importe quel client
Événements fire échoués dans les préférences de l’invité	plus de 60 par jour par invité au jeton expiré	0	Client 6.63
Vagues de recomposition sur guest_ok	à chaque numbers_update	uniquement en cas de changement réel	Client 6.64

Ce qui fonctionne immédiatement pour tous les clients (correctifs serveur)

Les protections serveur se situent dans le traitement des messages entrants — elles s’appliquent quelle que soit la version du client.

Déduplication par INSERT IGNORE in enqueueHostMsg — même si un client 6.55 envoie 1300 renouvellements identiques, un seul entre dans la file.
Une limite de 5 secondes sur host_hello et guest_hello — même si un client 6.55 se reconnecte chaque seconde, le deuxième hello d’affilée est fermé sans toucher la base.
Plafond pending_host_msgs = 500 par host_id — assurance contre la croissance de la file, quelle qu’en soit la source.
CDN-ready: $GLOBALS['apk_url'] in _config.php — passer à R2 ou à un CDN tient en une ligne, sans publier l’application.

Ce qui ne fonctionne qu’après la mise à jour du client

L’attente WebSocket de 60 secondes au profit de la stabilité (6.62) divise par dix la tempête de reconnexions du client.
L’attente exponentielle des reprises HTTP, 30 s → 30 min (6.64), divise par trente la charge de reprises.
Comparer avant d’incrémenter overridesVersion (6.64) économise le processeur local et la batterie, et réduit indirectement les reconnexions après Doze.
L’interface invité affiche un jeton expiré comme hors ligne (6.63), les événements échoués ne se produisent donc plus.

Décision : relevé $MIN = '6.66'. Tout ancien client, dès son premier versionCheck reçoit une boîte de dialogue bloquante Mettez à jour l’application (l’interface existe déjà, voir App.kt:checkVersionAsync).

Mettre Workerman à l’échelle — quand ce sera nécessaire

À l’heure actuelle count=1 — un unique processus PHP tient TOUS les WebSockets dans les tableaux $hosts/$guests/$calls in-memory.

Les seuils concrets :

10 000 connexions simultanées — confortable, avec de la marge.
15 000 simultanées — stable, mais des délais dépassés peuvent survenir au pic.
20 000 simultanées — le point critique. Une seule sortie de Doze chez 20 000 clients donne une file d’événements d’environ 500 secondes : délais dépassés et tempête.

Que faire à l’approche de 15 000 :

Installer Redis sur le VPS (apt install redis-server).
Workerman count=4 (selon le nombre de cœurs du VPS).
Move $hosts/$guests/$calls vers un HASH Redis avec TTL.
Pub/sub entre workers : un message arrive sur W1 alors que le destinataire est sur W2 — on le relaie par le canal.

Effect: mise à l’échelle linéaire jusqu’à 4×, le plafond passant à environ 40 000–60 000 simultanées.

Passer à un CDN — quand ce sera nécessaire

Aujourd’hui l’APK de 22 Mo est servi à chaque utilisateur depuis notre propre VPS. À cent mille, cela représente 2,2 To de trafic sortant par version — notre lien risque de ne pas suivre, ou de coûter cher.

Préparé en 6.64 :

$GLOBALS['apk_url'] in _config.php — une source de vérité unique pour l’adresse.
download.php et version_check.php la lisent depuis là.
Android vérifie lui-même la signature de l’APK : une substitution au CDN ne passera pas.

Quand le déménagement deviendra nécessaire :

Un bucket Cloudflare R2 → téléverser entrixy.apk.
Domaine personnalisé apk.entrixy.com via le CDN Cloudflare.
In _config.php: $GLOBALS['apk_url'] = 'https://apk.entrixy.com/entrixy.apk';
Dans le script de déploiement, après assembleRelease add r2 cp app-release.apk apk-bucket/entrixy.apk.

À l’échelle actuelle — des dizaines d’installations de test — aucun déménagement n’est nécessaire.

La liste des actions : ce qui se trouve maintenant sur le serveur et dans l’application

Pour que tous les correctifs prennent effet :

Sur le serveur : sudo supervisorctl restart dialer-ws.
Toute version inférieure à 6.66 recevra une boîte de dialogue de mise à jour obligatoire au prochain lancement.
Une fois la 6.66 déployée, la charge due aux tempêtes de reconnexion et aux reprises chute d’un ordre de grandeur.