Por que comprar um VPS é menos rápido do que um computador em casa? O problema é o servidor ou a linha?
Quando você acaba de comprar um VPS, muitas pessoas fazem uma coisa primeiro: abrem o SSH, tocam alguns comandos e sentem que a resposta é rápida. Quando o site realmente entrou em linha, a situação mudou – o fundo voltou, as imagens carregaram lentamente, o desktop remoto caiu, especialmente à noite. Olhando novamente para o Ping, o valor não parecia ser alto, então começou a duvidar se tinha comprado uma "máquina de contração".
Não se apresse a trocar pacotes. O VPS tem pelo menos três níveis de "rapidez": se o próprio servidor está sendo retardado, se a linha entre o servidor e o visitante está congestionada e se o programa do site está esperando um banco de dados ou uma interface externa. Mesurando apenas uma das camadas, é fácil gastar dinheiro no lugar errado.
VPS é lento, qual é o mais lento?
| O que você vê | Primeira suspeita | Primeira evidência |
| --- | --- | --- |
Entrada SSH com atraso e execução de comandos lenta CPU, memória, E/S de disco ou recursos de host top、free -h、 Disco de I/O.
SSH funciona bem, abertura de sites domésticos é lenta, linha de retorno, conexão entre redes, perda de pacotes ou conexão TCP, atraso TCP, mtr、TcpQuality |
| Ping baixo, mas tela inicial lenta | DNS, TLS, programas de origem, bancos de dados ou recursos de terceiros | curl -w segmentação demora tempo |
| Normal durante o dia, picos noturnos significativamente mais lentos | congestionamento de linhas, largura de banda compartilhada ou concorrência de picos de recursos | Revisão de intervalos horários e operadores |
| Rápido download e desktop remoto | Atraso, jitter e perda de pacotes para tráfego interativo | TCP 443/3389 Atraso e perda de pacotes |
Esta tabela não é uma conclusão para você, mas diz o que fazer primeiro. Por exemplo, "Ping baixo" só indica que o tempo de ida e volta do pacote de detecção do ICMP é curto, e não significa que a conexão TCP, a resposta da web e a transferência de arquivos grandes são rápidos.
Não mude de servidor, reserve o local nessa ordem
O mesmo VPS, o mesmo nome de domínio e a mesma rede local são testados em picos diurnos e noturnos, respectivamente. Registre o tempo, a cidade do cliente, a operadora, os comandos de teste e os resultados. Não reinstale o sistema, mude de CDN ou DNS ao mesmo tempo, caso contrário, os resultados não serão comparáveis.
Se você acabar de migrar o site, mantenha uma cópia da configuração atual e do registro. Depois da medição, altere uma variável, como apenas a mudança de linha ou apenas a atualização da memória, para saber exatamente de onde vem a melhoria.
* Teste em ordem fixa para evitar que os problemas de configuração sejam erroneamente classificados como problemas de linha. *
A CPU e a memória não são suficientes? O servidor de login pode ver
Veja o estado do servidor Linux em tempo real:
```bash
uptime
top
free -h
```
A questão não é a percentagem de um determinado segundo, mas a observação contínua de alguns minutos: se há processos que ocupam a CPU por muito tempo, se swaps são usados com frequência e se a carga ainda é alta quando não há acesso visível. O Windows VPS pode abrir o Gerenciador de Tarefas e observar a CPU, a memória, o disco e a rede separadamente, em vez de olhar apenas para a CPU.
Se apenas o site é lento, SSH e comandos do sistema estão funcionando, verifique primeiro o PHP-FPM, banco de dados, plugins e APIs externas; Se o sistema estiver bloqueado, considere aumentar a memória, ajustar o número de processos ou substituir o disco. Adicionar uma CPU não corrige a perda de pacotes de linha transfronteiriça, e vice-versa.
E/S de disco lento, será que a rede é lenta?
Quando um site salva artigos em segundo plano, descomprime arquivos ou consulta bancos de dados, a resposta do disco afeta diretamente o tempo de espera. Certifique-se de que o espaço não está preenchido:
```bash
df -h
lsblk
```
Quando uma observação mais detalhada é necessária, você pode executar depois de instalar sysstat:
```bash
iostat -xz 1 5
```
Veja as tendências ao longo do tempo: se o dispositivo está continuamente ocupado, se o rendimento de leitura e gravação é anormal e se a espera de E/S é elevada a longo prazo. Não use um pico súbito para determinar a corrupção do disco rígido, nem considere um "valor de escala" fixo na Internet como uma linha de recepção para todos os VPS. Diferentes tamanhos de virtualização, sistemas de arquivos e blocos de teste, os resultados não podem ser comparados diretamente.
Esta etapa pode ser usada em conjunto com a publicação [Como verificar VPS: uma lista de verificação de CPU, disco, largura de banda e linhas] (https://matrixidc.net/help/lfjtul/vps-performance-benchmark-guide). Esse artigo aborda o teste de entrega; Este artigo aborda "por que é lento depois de comprar de volta", não misturar os dois em uma conclusão.
A largura de banda é insuficiente ou o teste está errado?
Os pacotes de 30 Mbps, 100 Mbps, geralmente a velocidade de porta ou o calibre de pico, não equivalem a uma execução estável em qualquer momento, em qualquer região ou em qualquer site. A velocidade de download também pode ser afetada por servidores peer-to-peer, protocolos, números simultâneos, leitura de disco e caminhos entre redes.
A prática mais segura é fazer testes ponto a ponto com o iperf3 usando arquivos de teste fornecidos pelo fornecedor ou duas máquinas sob seu próprio controle. Não puxe dezenas de GB de arquivos repetidamente em estações de download públicas, muito menos "resultado de um único download de thread" como prova de qualidade de linha.
Se você usar o iperf3, você pode fazer isto quando ambos os extremos estão sob seu controle:
```bash
测试端启动服务（只在你控制的测试机上执行）
iperf3 -s
VPS 作为客户端连接测试机
iperf3 -c TEST_SERVER_IP -t 30
```
Desligue o serviço temporário após a conclusão do teste e certifique-se de que o firewall está liberando apenas as portas de teste necessárias. Este teste mostra apenas o rendimento entre as duas máquinas de teste e não representa a velocidade com que todos os usuários continentais visitam seu site.
Ping é baixo, por que é lento abrir a página?
É mais útil separar as solicitações da web do
que olhar para um número de ping. Para sites HTTPS, você pode executar:
```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://你的域名/
```
Se o tempo do DNS for alto, verifique primeiro a resolução e o serviço DNS; Se o tempo de conexão TCP ou TLS for alto, concentre-se no caminho de rede, na acessibilidade das portas e no aperto de mãos de certificados; Se os primeiros são rápidos e os primeiros bytes são altos, o problema está mais no programa de origem, no banco de dados ou na interface upstream; Se os primeiros bytes forem rápidos e o tempo total for alto, veja recursos estáticos como imagens, scripts e fontes.
Tenha em mente também que o ICMP pode ser desativado pelo servidor. Portas de destino podem ser medidas por TCP:
```bash
mtr -rwzc 100 --tcp --port 443 你的域名
```
Sem o mtr, você pode primeiro observar tendências com o ping e verificar solicitações HTTPS autênticas com a ferramenta de desenvolvedor do navegador ou o curl. Um salto no meio mostra a perda de pacotes, não significa que o pacote seja perdido definitivamente; Veja se os saltos e os pontos finais subsequentes ocorrem simultaneamente.
Como funciona o TCPQuality?
O script e os parâmetros estão aqui.
[TcpQuality] (https://github.com/ibsgss/TcpQuality) é um script de detecção de qualidade TCP que README indica que detecta nós de operadores de rede tripla chineses por padrão. Para VPS no exterior, o GitHub Raw é executado da seguinte forma:
```bash
bash <(curl -fsSL https://raw.githubusercontent.com/ibsgss/TcpQuality/main/runTcpQuality.sh)
```
Se você usar peixe:
```bash
curl -fsSL https:
//raw.githubusercontent.com/ibsgss/TcpQuality/main/runTcpQuality.sh | env TERM=xterm bash
```
Os servidores domésticos podem usar a entrada acelerada no projeto README:
```bash
bash <(curl -fsSL https://tcpquality.ibsgss.uk/run)
```
Recomendo baixar, verificar e executar primeiro.
Os scripts remotos não são endossados pelo provedor ou comandos próprios do sistema:
```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
```
Depois de confirmar a origem do script, o conteúdo e o propósito atual do teste, execute o teste formal. Por exemplo, detecte apenas IPv4 e defina o número de pacotes por nó para 30:
```bash
bash /tmp/runTcpQuality.sh -v4 -c 30
```
Os parâmetros comuns listados pelo README são os seguintes:
Parâmetros | Função |
| --- | --- |
| -c NUM | Número de pacotes por nó, 1–600, padrão 30 |
| -s NUM | Comprimento total do pacote IP, 0 é o SYN sem carga padrão |
| -p NUM | Número de nós paralelos, 1-31, padrão 16 |
| -v4 / -v6 | Detectar apenas IPv4 ou IPv6 |
| --only-large | Detecta apenas o retorno de pacotes IPv4 |
| --all | Detecção simultânea de velocidades IPv4/IPv6, Educational Network, Internet Internacional e Single Thread |
| --speedtest | Adicionar velocidade de medição de fio único após detecção de qualidade TCP |
| --intl | Execute o teste de conexão internacional separadamente ou adicione o teste em combinação |
| --province CODE | Detecta apenas províncias especificadas e também suporta abreviações como -bj, -sh e -gd |
| --debug | Manter arquivos temporários e sair informações de depuração |
* Veja o atraso, a perda de pacotes e o retorno de grandes pacotes, respectivamente, e depois verifique com portas de negócios reais. *
Não execute um monte de resultados diretamente com --all pela primeira vez. Execute novamente com a configuração padrão para salvar o link do relatório e a hora; Para localizar pacotes grandes, conexões internacionais ou throughput de thread único, adicione os parâmetros correspondentes separadamente. O significado e o escopo dos parâmetros dependem do item README e o --help também deve ser revisado após a atualização do script.
Antes de executar um script de terceiros, faça pelo menos três coisas: certifique-se de que está testando seu próprio VPS. Verifique o conteúdo do script e o endereço de download; Confirme o orçamento de firewall, permissões e tráfego. Os testes produzem fluxos de detecção e os testes de longo prazo, de alta concomitância ou de grandes pacotes não são adequados para serem executados repetidamente em picos de produção. Se o script exigir permissões adicionais, primeiro veja o que ele está fazendo, e não dê comandos desconhecidos diretamente ao root para "executar a pontuação".
Como avaliar o resultado após a análise?
Veja os recursos do sistema, a qualidade do TCP e o segmento de páginas da Web:
| Combinar resultados | Razões mais próximas | Próximo |
| --- | --- | --- |
| CPU/memória tensa a longo prazo, qualidade TCP normal | Configuração, carga de processo ou programa | Otimizar o programa antes de considerar recursos de atualização |
Recursos livres, mas atraso TCP de três redes / perda de pacotes aumenta significativamente no pico noturno | Linha ou interconexão de rede | Alteração de linha / nó, repetição de intervalos de tempo |
| TcpQuality normal, alto tempo de inicialização da página | Estação de origem, banco de dados, DNS ou interface upstream | Veja os logs de aplicativos e segmentação de solicitações |
| Velocidade de thread único em geral, throughput multi-thread ainda disponível | Limitações de peer-to-peer ou características de conexão única | Teste simultâneo de negócios reais, não olhe apenas para picos |
| Apenas uma operadora é anormal | Problemas de conexão na direção da operadora | Usar a rede da operadora para repetir e solicitar instruções de roteamento |
| Todas as métricas estão funcionando e os usuários ainda sentem o cartão | Rede local, navegador, recurso estático ou experiência de negócios | Revisão com redes de usuários reais e cascatas de páginas |
Em particular, faça três repetições: dia útil, pico noturno e fim de semana. Procure telecomunicações, conectividade e teste de redes móveis. Um resultado só pode descrever esse momento e não pode ser concluído por todo o mês ou por todos os usuários.
Quando atualizar a configuração e quando mudar de linha?
Se os comandos do sistema, consultas de banco de dados e E/S de disco estiverem apertados, atualizar a memória ou substituir o armazenamento mais adequado é mais direto do que mudar de linha cega. Se os recursos estão disponíveis, a conexão TCP doméstica está claramente agitada no pico tardio, continuar a adicionar CPU e disco geralmente não resolve o problema e deve comparar linhas ou nós diferentes.
Se você ainda não comprou, veja [Página do produto VPS da MatrixIDC] (https://matrixidc.net/) para verificar a configuração real, testar IP, calibre de largura de banda e regras de reembolso/renovação; Se já estiver em uso, você também pode testar as mesmas condições com seu nome de domínio e porta de negócio antes de decidir se migrar. A MatrixIDC fornece informações sobre nós, configurações e linhas, sem garantir que todas as regiões, todas as operadoras e todos os períodos de tempo sejam tão rápidos. Em última análise, ainda deve ser baseado em seu cenário de negócios.
Resposta direta: Por que o VPS não é tão rápido quanto o computador em casa?
Os cartões de VPS não são necessariamente de baixa configuração e as razões comuns incluem a competição de recursos, congestionamento de linhas transfronteiriças, limitações de largura de banda, E/S de disco e lenta resposta de aplicativos. A CPU, o disco, a largura de banda, a latência TCP, a perda de pacotes e a carga de página devem ser testados separadamente para decidir se a configuração deve ser atualizada ou se a linha deve ser substituída.
Perguntas frequentes
O TcpQuality com uma pontuação alta provará que o VPS é rápido?
Não posso. Ele reflete principalmente a qualidade do TCP quando os scripts detectam os nós, e não pode substituir suas páginas da Web. API、 A implementação de desktops remotos e bancos de dados também não garante que os picos tardios não mudem no futuro.
Qual é o Ping e TcpQuality?
Ambos usos são diferentes. Ping para ver rapidamente as tendências de ida e volta do ICMP; TcpQuality está mais perto da detecção TCP e da qualidade tridimensional. Finalmente, a autenticação é carregada com portas e páginas reais do negócio.
O script de teste precisa usar root?
root não deve ser usado por padrão. Veja primeiro o script e as informações de ajuda; Execute as instruções do script somente se confirmar que um teste realmente precisa de permissões. Não entregue scripts desconhecidos diretamente ao root.
Por que o mesmo VPS é rápido e móvel lento?
A conexão e o roteamento de diferentes operadores para a sala de máquinas podem ser diferentes. O TCP 443, a perda de pacotes e os primeiros bytes de página devem ser testados de três redes separadamente, não usando um dos resultados para representar todos os usuários.
Em vez de maior largura de banda, o acesso será rápido?
Não necessariamente. Uma largura de banda maior resolve o limite máximo de throughput, que não resolve a alta latência, a perda de pacotes, o DNS lento, o processamento lento da estação de origem ou a redução de recursos de terceiros. Confirme primeiro os gargalos e decida se atualizar.
Referências
- [Repositório Oficial TcpQuality e README] (https://github.com/ibsgss/TcpQuality): Os comandos, o âmbito dos parâmetros e o tipo de teste dependem da descrição atual do projeto.
- [Huawei Cloud: O que fazer para acessar sites não chineses lentamente] (https://support.huaweicloud.com/hecs_faq/hecs_faq_0603.html): combina Ping, pacotes perdidos e verificação geográfica.
- [Tencent Cloud: Percurso lento de busca de acesso ao site] (https://cloud.tencent.com/document/product/213/14632): Localização a partir de DNS e recursos de instância.
