Serveurs nécessaires selon la charge et la marge de sécurité
Ce calculateur transforme une prévision de trafic en objectif concret de mise à l'échelle horizontale.
Lancer gratuitement
Indiquez le débit maximal visé, la capacité mesurée d'un serveur et le pourcentage à conserver comme marge de sécurité. L'outil réduit la capacité exploitable de chaque serveur, divise la charge cible par cette valeur, puis arrondit au nombre entier supérieur. Il présente aussi les capacités provisionnée et exploitable, la réserve restante et l'utilisation prévue afin que vous puissiez contrôler chaque hypothèse.
Partez d'une charge cible et d'une capacité mesurées
Un dimensionnement fiable repose sur des mesures compatibles. Saisissez le débit soutenu maximal que le déploiement doit absorber, et non une moyenne quotidienne qui masque les pointes. Mesurez la capacité par serveur lors d'un test représentatif utilisant la même version d'application, le même type d'instance, la même composition de requêtes, les mêmes dépendances et le même objectif de latence qu'en production. Les deux valeurs sont exprimées en requêtes par seconde. Si un serveur n'atteint un débit supérieur qu'en dépassant l'objectif de service, ne retenez pas ce débit. Une cible nulle est acceptée, mais la capacité doit être positive. Le résultat reste une base de planification : bases de données, files, caches, connexions, services externes et requêtes lentes peuvent limiter le système plus tôt. Recalculez dès que la charge ou les mesures évoluent.
Conservez une marge pour éviter la saturation
La marge de sécurité correspond à la part de capacité mesurée volontairement laissée libre sur chaque serveur. Avec 25 pour cent de marge, un serveur testé à 1 200 requêtes par seconde contribue à hauteur de 900 au calcul. Cette réserve absorbe les pointes, les erreurs de prévision et le délai de démarrage des instances, tout en limitant la hausse de latence à l'approche de la saturation. Le taux approprié dépend de l'exploitation. Un service interne stable et rapide à démarrer peut accepter une réserve plus faible ; une API publique irrégulière, lente à chauffer ou soumise à une latence stricte peut en demander davantage. Saisissez une valeur comprise entre zéro inclus et 100 exclu. La marge est appliquée avant la division, puis le résultat est arrondi au supérieur. Comparez plusieurs taux pour rendre visible l'arbitrage entre résilience et coût.
Transformez le résultat en décision de provisionnement
Le résultat principal est le nombre entier minimal de serveurs identiques dont la capacité ajustée atteint la cible. La capacité exploitable par serveur reflète la réserve appliquée. La capacité provisionnée représente le débit nominal total, tandis que la capacité exploitable provisionnée indique ce que le plan autorise à consommer. La capacité exploitable restante résulte de l'arrondi supérieur. Le taux d'utilisation compare la charge cible à la capacité nominale totale. Appuyez-vous sur ces données pour justifier un minimum d'autoscaling, une flotte fixe ou un budget, puis testez la topologie et les défaillances. La haute disponibilité, les zones, la maintenance, les répliques ou la perte d'une instance peuvent nécessiter davantage de serveurs. Le calculateur n'ajoute pas cette redondance : appliquez ensuite vos contraintes d'architecture et recommencez lorsque les instances ou les performances changent.
Cas d’usage
Définir un socle d'autoscaling
Convertissez la pointe prévue et le débit mesuré en nombre minimal d'instances avec une réserve explicite.
Comparer des types d'instances
Appliquez la même cible aux capacités mesurées de plusieurs tailles de serveur avant de provisionner.
Documenter une revue de capacité
Consignez la cible, le test, la marge, l'utilisation et la réserve qui justifient votre décision.
Questions fréquentes
Comment le nombre de serveurs est-il calculé ?
La capacité exploitable égale la capacité par serveur multipliée par un moins le pourcentage de marge. La charge est divisée par cette valeur, puis arrondie au supérieur.
Quelle capacité par serveur faut-il indiquer ?
Utilisez le débit soutenu d'un test représentatif qui respecte vos objectifs de latence et d'erreur avec une configuration proche de la production.
La marge implique-t-elle des serveurs supplémentaires ?
Elle réduit la capacité attribuée à chaque serveur et peut augmenter la flotte arrondie. La réserve couvre les pointes, les démarrages et les erreurs de prévision.
Le résultat inclut-il la redondance haute disponibilité ?
Non. Il calcule uniquement le minimum lié au débit. Ajoutez les instances nécessaires aux zones, répliques, quorums, maintenances et autres règles de résilience.
Quel est le prix d'une requête API ?
Chaque calcul par API coûte $0.002. Vous pouvez aussi utiliser gratuitement ce même calculateur déterministe dans votre navigateur.
Pour les développeurs — accès API
Tout sur cette page est disponible par programmation. Cette section s'adresse aux équipes qui veulent l'intégrer à leurs systèmes ; les autres peuvent simplement utiliser l'outil ci-dessus.
Endpoint
Authentification par jeton Bearer : un seul POST met la tâche en file d’attente, et le résultat vous parvient par webhook ou lien signé.
Appeler depuis votre stack
curl -X POST https://api.kit.forhosting.com/dev/servers-needed \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"target_request_rate":10000,"per_server_capacity":1200,"headroom_percent":25}'const res = await fetch("https://api.kit.forhosting.com/dev/servers-needed", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"target_request_rate": 10000,
"per_server_capacity": 1200,
"headroom_percent": 25
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/dev/servers-needed",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"target_request_rate": 10000,
"per_server_capacity": 1200,
"headroom_percent": 25
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/dev/servers-needed", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"target_request_rate":10000,"per_server_capacity":1200,"headroom_percent":25}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"target_request_rate":10000,"per_server_capacity":1200,"headroom_percent":25}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/dev/servers-needed", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Exemple de requête
{
"target_request_rate": 10000,
"per_server_capacity": 1200,
"headroom_percent": 25
}Exemple de réponse
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "dev.servers_needed",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}L’API est asynchrone : chaque appel renvoie un task_id immédiatement, puis vous interrogez l’état à raison d’une requête par seconde.
Tarifs
Le prix est publié, sans tokens ni crédits. Une tâche qui échoue n’est pas facturée.
Erreurs
| HTTP | Code | Signification |
|---|---|---|
401 | unauthorized | Clé API absente ou invalide : vérifiez l’en-tête Authorization. |
402 | insufficient_balance | Solde insuffisant : rechargez votre compte pour lancer cette tâche. |
404 | unknown_type | Type de tâche inconnu : vérifiez le champ type de votre requête. |
429 | rate_limited | Trop de requêtes : ralentissez la cadence, puis réessayez. |