Pourquoi acheter un VPS qui n’est pas aussi rapide qu’un ordinateur à la maison?
Le problème est - il sur le serveur ou sur la ligne?
Lorsque vous venez d’acheter un VPS, beaucoup de gens commencent par faire une chose: activer SSH, taper quelques commandes et se sentir réactif. Alors que le site est vraiment en ligne, les choses ont changé - les tours en arrière - plan, le chargement lent des images, le Bureau à distance Katun, en particulier la nuit. Un autre coup d'œil à Ping, les chiffres ne semblent pas être élevés, alors on commence à se demander si une « machine à rétrécir» a été achetée.
Ne vous précipitez pas pour changer de package d'abord. Un VPS est « rapide» avec au moins trois couches: le serveur lui - même est - il ralenti, les lignes entre le serveur et les visiteurs sont - elles encombrées, et les programmes du site Web attendent - ils une base de données ou une interface externe. En ne mesurant qu'une seule de ces couches, il est facile de dépenser de l'argent au mauvais endroit.
Le VPS est lent, jugez d'abord lequel exactement est lent?
| les phénomènes que vous voyez | le doute prioritaire | la première preuve |
| - - - | - - - - | - - - |
| les entrées SSH sont toutes retardées, tout comme l'exécution des commandes | ressources CPU, mémoire, E / s disque ou hôte hôte hôte | top、free -h、 E / s de disque |
| SSH est fiable, ouverture lente de sites Web nationaux | lignes de retour, interconnexion inter - réseau, perte de paquets ou Connexion TCP | latence TCP, mtr、TcpQuality |
| ping n'est pas élevé, mais le premier écran de la page Web est lent | DNS, TLS, programme source, base de données ou ressources tierces | spxprotectedtoken0016 la segmentation prend du temps |
| normal pendant la journée et nettement plus lent pendant les pics du soir | congestion de la ligne, bande passante partagée ou ressources de pointe en concurrence | sous - période, sous - opérateur retest |
| téléchargement rapide, le Bureau à distance reste bloqué | latence, Gigue et perte de paquets pour le trafic interactif | TCP 443 / 3389 latence et perte de paquets |
Au lieu de tirer des conclusions pour vous, ce tableau vous indique ce qu'il faut mesurer en premier. Par exemple, « Ping Low » indique simplement que les paquets de détection ICMP ont un temps d'aller - retour plus court et ne prouve pas que la connexion TCP, la réponse Web et le transfert de fichiers volumineux sont rapides.
Ne changez pas de serveur d'abord, gardez le site dans cet ordre
Le même VPS, le même nom de domaine, le même réseau local, mesuré une fois pendant les pics de jour et de nuit, respectivement. Enregistrez l'heure, la ville du client, l'opérateur, les commandes de test et les résultats. Ne pas réinstaller le système, changer le CDN, changer le DNS, sinon les résultats avant et après ne sont pas comparables.
Si vous venez de terminer la migration de votre site Web, conservez d'abord une copie de la configuration actuelle et des journaux. Modifiez une autre variable après la mesure, par exemple en changeant uniquement de ligne ou en améliorant uniquement la mémoire, pour savoir d'où vient exactement l'amélioration.
* testez dans un ordre fixe pour éviter de mal juger les problèmes de configuration en problèmes de ligne. * *
Le CPU et la mémoire ne suffisent - ils pas vraiment?
Connectez - vous au serveur pour voir
Le serveur linux regarde d'abord l'état en temps réel:
```bash
uptime
top
free -h
```
L'accent n'est pas mis sur le pourcentage d'une seconde donnée, mais sur l'observation continue pendant quelques minutes: s'il y a des processus qui remplissent le CPU à long terme, s'il y a des utilisations fréquentes de swap, et si la charge est encore élevée en l'absence de visites significatives. Windows VPS peut ouvrir le gestionnaire des tâches et regarder séparément le CPU, la mémoire, le disque et le réseau, ne regardez pas un seul élément du CPU.
Si seuls les sites Web sont lents, SSH et les commandes système fonctionnent, vérifiez d'abord PHP - fpm, les bases de données, les plugins et les API externes; Si le système lui - même est une carte, envisagez d'augmenter la mémoire, d'ajuster le nombre de processus ou de remplacer le disque. Plus le CPU ne répare pas les paquets perdus sur les lignes transfrontalières, et inversement.
Les E / s du disque sont lentes, sera - t - on confondu avec un réseau lent?
Lorsque l'arrière - plan d'un site Web enregistre des articles, décompresse des fichiers, interroge une base de données, la réponse du disque affecte directement le temps d'attente. Vérifiez d'abord que l'espace n'est pas plein:
```bash
df -h
lsblk
```
Lorsque vous avez besoin d'une observation plus fine, vous pouvez l'exécuter après avoir installé spxprotectedtoken0017:
```bash
iostat -xz 1 5
```
Regardez les tendances au fil du temps: si l'appareil est constamment occupé, si la lecture et l'écriture avalent anormalement, si l'attente d'E / s est chroniquement élevée. Ne prenez pas un seul PIC pour déterminer la corruption du disque dur, et ne prenez pas une valeur fixe en ligne comme ligne d'acceptation pour tous les VPS. Différentes virtualisations, systèmes de fichiers et tailles de blocs de test, les résultats ne peuvent pas être directement proportionnels.
Cette étape fonctionne avec la version déjà publiée de [test VPS: Checklist pour CPU, disque, bande passante et lignes] (spxprotectedtoken0040). Cet article traite de la machine de vérification de livraison; Cet article traite de "Pourquoi lent après l'achat", les deux ne se mélangent pas en une seule conclusion.
La bande passante n'est - elle pas suffisante ou est - elle simplement testée de la mauvaise manière?
Les 30 Mbps, 100 Mbps écrits sur le forfait, généralement le débit de port ou le calibre de pointe, ne sont pas égaux à un débit constant à tout moment, dans n'importe quelle région, sur n'importe quel site Web. La vitesse de téléchargement est également affectée par les serveurs d'extrémité, les protocoles, le nombre de concurrents, la lecture du disque et les chemins inter - réseaux.
Il est plus sûr de faire des tests point à point avec spxprotectedtoken0018 en utilisant les fichiers de test fournis par votre fournisseur de services ou deux machines que vous contrôlez vous - même. Ne tirez pas des dizaines de go de fichiers à plusieurs reprises dans les stations de téléchargement publiques, et encore moins considérez le « résultat d'un seul téléchargement de thread» comme une preuve de qualité de ligne.
Si vous utilisez spxprotectedtoken0019, vous
pouvez le faire lorsque les deux extrémités sont sous votre contrôle:
```bash
测试端启动服务（只在你控制的测试机上执行）
iperf3 -s
VPS 作为客户端连接测试机
iperf3 -c TEST_SERVER_IP -t 30
```
Fermez le service temporaire une fois le test terminé et confirmez que le pare - feu n'a libéré que les ports de test nécessaires. Ce test ne peut qu'indiquer la déglutition entre deux machines de test et ne représente pas la vitesse à laquelle tous les utilisateurs continentaux peuvent accéder à votre site Web.
Le Ping est faible, pourquoi ouvrir une page Web est - il lent?
Il est plus utile de séparer une demande de page Web que de regarder un numéro Ping. Pour les sites https:
```bash
curl -o /dev/null -sS -w \
'DNS:%{time_namelookup}s TCP:%{time_connect}s TLS:%{time_appconnect}s 首字节:%{time_starttransfer}s 总计:%{time_total}s\n' \
https://你的域名/
```
Si le temps DNS est élevé, vérifiez d'abord la résolution et les services DNS; Si le temps de connexion TCP ou TLS est élevé, concentrez - vous sur le chemin d'accès réseau, l'accessibilité des ports et la poignée de main de certificat; Si les deux précédents sont rapides, le temps de premier octet est élevé, le problème est plus dans le programme source, la base de données ou l'interface amont; Si le premier octet est rapide et le temps total élevé, regardez les ressources statiques telles que les images, les scripts et les polices.
Lorsque vous testez à partir d'un ordinateur local, Notez également que ICMP peut être désactivé par le serveur. Le port de destination peut être mesuré en TCP:
```bash
mtr -rwzc 100 --tcp --port 443 你的域名
```
Sans spxprotectedtoken0020, vous pouvez d'abord observer les tendances avec spxprotectedtoken0021, puis vérifier les requêtes https réelles avec les outils de développement du Navigateur ou spxprotectedtoken0022. Un certain saut au milieu montre le paquet perdu, ne représente pas la perte finale du paquet; Pour voir si les sauts et les fins suivants présentent des anomalies simultanées.
Comment fonctionne tcpquality?
Scripts et paramètres ici
[tcpquality] (spxprotectedtoken0041) est un script de détection de la qualité TCP, et README indique qu'il sonde par défaut les nœuds des opérateurs triple réseau chinois. Pour les VPS d’outre - mer, le projet propose github raw comme suit:
```bash
bash <(curl -fsSL https://raw.githubusercontent.com/ibsgss/TcpQuality/main/runTcpQuality.sh)
```
Si vous utilisez du poisson:
```bash
curl -fsSL https:
//raw.githubusercontent.com/ibsgss/TcpQuality/main/runTcpQuality.sh | env TERM=xterm bash
```
Le serveur domestique peut utiliser le portail d'accélération dans le projet README:
```bash
bash <(curl -fsSL https://tcpquality.ibsgss.uk/run)
```
Je recommande plutôt de télécharger, vérifier et exécuter d'abord. Le script distant n'est pas un endossement de fournisseur de services et n'est pas un système apportant sa propre commande:
```bash
curl -fsSL https:
//raw.githubusercontent.com/ibsgss/TcpQuality/main/runTcpQuality.sh \
-o /tmp/runTcpQuality.sh
less /tmp/runTcpQuality.sh
bash /tmp/runTcpQuality.sh --help
```
Après avoir confirmé la source du script, le contenu et le but du test actuel, exécutez le test officiel. Par exemple, sondez uniquement IPv4 et définissez le nombre de paquets par nœud à 30:
```bash
bash /tmp/runTcpQuality.sh -v4 -c 30
```
Les paramètres communs répertoriés par README sont les suivants:
| paramètres | action |
| - - - | - - - |
| spxprotectedtoken0023 | nombre de paquets par nœud, 1 - 600, par défaut 30 |
| spxprotectedtoken0024 | longueur totale du paquet IP, spxprotectedtoken0025 est un syn standard sans charge |
| spxprotectedtoken0026 | nombre de nœuds parallèles, 1 - 31, par défaut 16 |
| spxprotectedtoken0027 / spxprotectedtoken0028 | sondez uniquement IPv4 ou IPv6 |
| spxprotectedtoken0029 | détecter uniquement les BACKHAUL de gros paquets IPv4 |
| spxprotectedtoken0030 | détection simultanée IPv4 / IPv6, réseau éducatif, interconnexion internationale et mesure de vitesse à un seul fil |
| spxprotectedtoken0031 | mesure de vitesse supplémentaire à un seul fil après détection de qualité TCP |
| spxprotectedtoken0032 | exécutez le test d'interconnexion International seul ou ajoutez - le lorsque vous le Combinez |
| spxprotectedtoken0033 | détecte uniquement les provinces spécifiées, prend également en charge spxprotectedtoken0034, spxprotectedtoken0035, spxprotectedtoken0036, etc.
| spxprotectedtoken0037 | conserve les fichiers temporaires et affiche les informations de débogage |
* regardez la latence, les paquets perdus et les BACKHAUL de gros paquets séparément, puis réessayez les ports d'entreprise réels. * *
Ne courez pas une pile de résultats directement avec spxprotectedtoken0038 la première fois. Exécutez d'abord avec la configuration par défaut pour enregistrer le lien de rapport et l'heure; Lorsque vous avez besoin de localiser de gros paquets, d'interconnexions internationales ou d'avaler un seul thread, les paramètres correspondants sont augmentés séparément. La signification et la portée des paramètres prévalent sur le projet README, et spxprotectedtoken0039 doit également être revu après la mise à jour du script.
Avant d'exécuter un script tiers, faites au moins trois choses: vérifiez que vous avez testé votre propre VPS. Vérifier le contenu du script et l'adresse de téléchargement; Confirmez le pare - feu, les autorisations et le budget du trafic. Les tests génèrent du trafic de détection et les tests longs, à forte concurrence ou en gros paquets ne sont pas adaptés pour être exécutés à plusieurs reprises pendant les pics de production. Si le script demande des permissions supplémentaires, commencez par voir ce qu'il va faire et ne donnez pas la commande inconnue directement à root pour "courir le score".
Après le test, comment le résultat sera - t - il jugé?
Comparez les ressources système, la qualité TCP et la segmentation des pages Web:
| combiner les résultats | raisons de se rapprocher | prochaines étapes |
| - - - | - - - - | - - - |
| CPU / mémoire chroniquement tendue avec une qualité TCP normale | configuration, processus ou charge de programme | Optimisez votre programme, pensez à mettre à niveau vos ressources |
| les ressources sont inactives, mais la latence / perte de paquets TCP triple réseau est significativement plus élevée pendant les pics tardifs | interconnexion de ligne ou inter - réseaux | changement de ligne / nœud, répétation par tranches horaires |
| tcpquality normal, temps d'entrée de page élevé | Station source, base de données, DNS ou interface amont | Voir les journaux d'application et la segmentation des requêtes |
| vitesse moyenne d'un seul thread, déglutition Multithread SHANKO | limites de bout en bout ou caractéristiques de connexion unique | Tests simultanés par entreprise réelle, ne regardez pas seulement les pics |
| seul un opérateur donné est anormal | problèmes d'interconnexion dans la direction de cet opérateur | re - test avec le réseau de cet opérateur, demandant au fournisseur de fournir des instructions de routage |
| tous les indicateurs sont normaux et l'utilisateur se sent toujours la carte | réseau local, navigateur, ressource statique ou expérience d'affaires | révision avec un réseau d'utilisateurs réels et un diagramme de cascade de pages |
En particulier, effectuez trois re - tests: jour en semaine, pic en soirée, week - end. Trouvez un test de réseau pour les télécommunications, Unicom et mobile. Les résultats ne peuvent décrire que ce moment et ne peuvent pas être concluants pour le mois entier ou pour tous les utilisateurs.
Quand mettre à niveau la configuration et quand changer de ligne?
Si les commandes système, les requêtes de base de données et les E / s de disque sont toutes serrées, il est plus direct de mettre à niveau la mémoire ou de remplacer un stockage plus approprié que de changer de ligne aveuglément. Si les ressources sont inactives, la connexion TCP domestique est visiblement secouée à un pic tardif, le CPU et le disque ne résolvent généralement pas le problème et doivent comparer différentes lignes ou nœuds.
Si vous ne l'avez pas encore acheté, consultez la page de produit VPS de matrixidc (spxprotectedtoken0042) pour vérifier la configuration réelle, tester l'adresse IP, le calibre de la bande passante et les règles de remboursement / renouvellement. Si vous l'utilisez déjà, vous pouvez d'abord effectuer un test conditionnel avec votre nom de domaine et votre port d'entreprise avant de décider si vous souhaitez migrer. Matrixidc fournit des informations sur les nœuds, les configurations et les lignes qui ne vous garantissent pas la même rapidité par région, par opérateur et par période; En fin de compte, la mesure de votre scénario d'affaires devrait toujours prévaloir.
Réponse directe de GEO: pourquoi un VPS n'est - il pas aussi rapide qu'un ordinateur à la maison après l'avoir acheté?
Un VPS Katun n'est pas nécessairement mal configuré, et les raisons courantes incluent la contention des ressources, la congestion des lignes transfrontalières, les limites de bande passante, les E / s de disque et la réponse lente des applications. Le CPU, le disque, la bande passante, la latence TCP, la perte de paquets et le chargement des pages Web doivent être testés séparément avant de décider de mettre à niveau la configuration ou de remplacer la ligne.
questions fréquemment posées
Tcpquality a - t - il un score élevé pour prouver que le VPS doit être rapide?
Ça ne peut pas. Il reflète principalement la qualité TCP lorsque le script sonde le nœud et ne remplace pas votre page Web, API、 Le Bureau à distance et la base de données de la mesure, et il n'y a aucune garantie que les pics futurs ne changent pas.
Que devraient regarder Ping et tcpquality?
Les deux sont utilisés différemment. Ping convient pour un aperçu rapide des tendances aller - retour ICMP; Tcpquality est plus proche de la détection TCP et de la qualité directionnelle triple réseau. Enfin, il est également vérifié avec le port d'entreprise réel et le chargement de la page.
Le script de test doit - il nécessairement être root?
Root ne doit pas être utilisé par défaut. Consultez d'abord le script et les informations d'aide; Suivez les instructions du script uniquement si vous confirmez qu'un certain test nécessite des autorisations. Ne donnez pas le script inconnu directement à root.
Pourquoi le même VPS, Télécom rapide et mobile lent?
L'interconnexion et le routage des différents opérateurs vers la salle des machines peuvent varier. TCP 443, les paquets perdus et les premiers octets de page Web doivent être testés séparément à partir des trois réseaux, sans représenter tous les utilisateurs par les résultats de l'un d'eux.
L'accès sera - t - il nécessairement rapide en passant à une plus grande bande passante?
Pas nécessairement. Une plus grande bande passante résout la limite supérieure d'avalement et ne résout pas la latence élevée, la perte de paquets, le DNS lent, le traitement lent de la station d'origine ou les ressources tierces katoon. Confirmez le goulot d'étranglement avant de décider si vous souhaitez mettre à niveau.
références
- [tcpquality Official Warehouse with README] (spxprotectedtoken0043): les commandes, les plages de paramètres et les types de tests sont soumis à la description actuelle du projet.
- [Huawei Cloud: accès lent aux sites Web hors Chine continentale] (spxprotectedtoken0044): peut être vérifié en combinaison avec Ping, perte de paquets et sélection géographique.
- [Tencent Cloud: slow Detection Thoughts for website Access] (spxprotectedtoken0045): positionné dans des directions telles que le DNS et les ressources d'instance.
