Почему VPS не такой быстрый, как домашний компьютер?
Проблема в серверах или линиях?
Когда вы только что купили VPS, многие люди сначала сделают одно: включите SSH, постучите несколько команд и почувствуйте быстрый ответ. Когда сайт действительно в сети, ситуация изменилась - задний поворот, медленная загрузка изображений, удаленный рабочий стол Катон, особенно заметно ночью. Взгляните еще раз на Ping, значение не кажется высоким, поэтому начинает задаваться вопросом, была ли куплена « машина для сжатия».
Не спешите менять еду. У VPS есть, по крайней мере, три уровня быстроты: замедляется ли сам сервер, перегружена ли линия между сервером и посетителем, ждет ли веб - программа базы данных или внешнего интерфейса. Измерите только один слой, и легко потратить деньги в неправильном месте.
VPS медленный, чтобы определить, какой именно медленный?
Явление, которое вы видите, приоритет сомнения, первое доказательство.
Да.
Запуск SSH задерживается, а выполнение команд также медленное? CPU, память, диск I / O или хост - ресурсы. top、free -h、 Диск I / O.
SSH очень гладкий, отечественное открытие веб - сайта медленный путь назад, межсетевое подключение, потеря пакетов или TCP - соединение, задержка TCP, mtr、TcpQuality |
Ping невелик, но веб - экран очень медленный. / DNS, TLS, исходные станции, базы данных или сторонние ресурсы.
Нормальный день, поздний пик значительно замедляется #
перегруженность линий, общая пропускная способность или пиковые ресурсы конкурируют за время разделения, повторное измерение субоператоров.
Быстрая загрузка, удаленный рабочий стол по - прежнему застрял в задержке, дрожании и потере пакетов интерактивного трафика, TCP 443 / 3389 Задержка и потеря пакетов.
Эта таблица не делает выводы для вас, а говорит вам, что вы измеряете первым. Например, « низкий Ping» показывает, что пакет обнаружения ICMP имеет более короткое время в оба конца и не доказывает, что TCP - соединение, веб - ответ и передача больших файлов являются быстрыми.
Не меняйте сервер, оставьте место в этом порядке
Один и тот же VPS, один и тот же домен и одна и та же локальная сеть измеряются один раз в дневное время и один раз в ночное время. Запишите время, город, в котором находится клиент, оператор, команду тестирования и результаты. Не перезагружайте систему, не меняйте CDN и не меняйте DNS, иначе результаты до и после не будут сопоставимы.
Если вы только что переехали на сайт, сначала сохраните текущую конфигурацию и журнал. Измените переменную после измерения, например, просто поменяйте линию или просто обновите память, чтобы узнать, откуда взялось улучшение.
* Тестирование в фиксированном порядке, с тем чтобы избежать ошибочного определения проблемы конфигурации как проблемы с линией. *
CPU и памяти действительно недостаточно?
На сервере можно посмотреть.
Сервер Linux в режиме реального времени:
```bash
uptime
top
free -h
```
Акцент делается не на проценте секунды, а на постоянном наблюдении в течение нескольких минут: есть ли длительные процессы, заполненные процессором, часто ли используется swap, и остается ли нагрузка высокой, когда нет очевидного количества посещений. Windows VPS может включать диспетчер задач и наблюдать за ЦП, памятью, диском и сетью отдельно, а не только за одним ЦП.
Если только медленный веб - сайт, SSH и системные команды являются нормальными, сначала проверьте PHP - FPM, базы данных, плагины и внешние API; Если система сама по себе застряла, подумайте об увеличении памяти, настройке числа процессов или замене диска. Добавление CPU не устраняет потери пакетов на трансграничных линиях, и наоборот.
Диск I / O медленный, не ошибочно ли вы считаете сеть медленной?
При сохранении статей, декомпрессии файлов и запросе базы данных в фоновом режиме веб - сайта ответ диска напрямую влияет на время ожидания. Сначала убедитесь, что пространство не заполнено:
```bash
df -h
lsblk
```
Если требуется более детальное наблюдение, можно установить sysstat после запуска:
```bash
iostat -xz 1 5
```
Посмотрите на тенденции в течение определенного периода времени: является ли устройство постоянно занятым, является ли поглощение чтения и записи ненормальным, а ожидание ввода / вывода слишком высоким в течение длительного времени. Не используйте внезапный пик, чтобы определить повреждение жесткого диска, и не используйте фиксированное « значение соответствия» в Интернете в качестве линии приемки для всех VPS. Различные размеры виртуализации, файловых систем и тестовых блоков не могут быть напрямую пропорциональны.
Этот шаг может быть использован в сочетании с опубликованным [VPS Technology Measure: CPU, диски, контрольный список полос пропускания и линий] (https://matrixidc.net/help/lfjtul/vps-performance-benchmark-guide). В этой статье речь идет о доставке контрольной машины; В этой статье решается вопрос: « Почему медленно после покупки? », и эти два не смешиваются в один вывод.
Недостаточная пропускная способность или просто неправильный способ тестирования?
Написанные в пакете 30 Мбит / с, 100 Мбит / с, как правило, скорость порта или пиковый калибр, не равны стабильному заполнению в любое время, в любом регионе или на любом веб - сайте. Скорость загрузки также зависит от оконечных серверов, протоколов, параллельных чисел, чтения дисков и кросс - сетевых маршрутов.
Лучше всего использовать тестовые файлы, предоставленные поставщиком услуг, или две машины, которые вы контролируете, для проведения одноранговых тестов с помощью iperf3. Не перетаскивайте десятки ГБ файлов неоднократно на публичных станциях загрузки, не говоря уже о том, чтобы использовать « результат загрузки в одну потоку» в качестве доказательства качества линии.
Если вы используете iperf3, вы можете сделать это, когда оба конца находятся под вашим контролем:
```bash
测试端启动服务（只在你控制的测试机上执行）
iperf3 -s
VPS 作为客户端连接测试机
iperf3 -c TEST_SERVER_IP -t 30
```
После завершения тестирования отключите временную службу и убедитесь, что брандмауэр запускает только необходимые тестовые порты. Этот тест может только показать пропускную способность между двумя тестовыми машинами, а не скорость, с которой все пользователи на континенте посещают ваш сайт.
Ping очень низкий, почему вы открываете веб - страницу или медленно?
Раскройте веб - запрос, чтобы он был полезнее, чем смотреть на цифру Ping. На сайте 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://你的域名/
```
Если время DNS велико, сначала проверьте аналитику и службу DNS; Если время подключения TCP или TLS велико, обратите внимание на сетевой путь, доступность порта и рукопожатие сертификата; Если все впереди быстро, но время ввода очень велико, проблема больше в исходной станции, базе данных или интерфейсе вверх по течению; Если заголовок быстр и общий объем времени высок, посмотрите на статические ресурсы, такие как изображения, сценарии и шрифты.
При измерении с локального компьютера обратите внимание, что ICMP может быть отключен сервером. Целевые порты можно измерить с помощью TCP:
```bash
mtr -rwzc 100 --tcp --port 443 你的域名
```
При отсутствии mtr можно понаблюдать за тенденциями с помощью ping, а затем проверить реальные запросы HTTPS с помощью инструмента разработчика браузера или curl. Один прыжок посередине показывает потерянную сумку, не означает, что в конечном итоге она должна быть потеряна; Это зависит от того, будут ли последующие прыжки и финишные точки ненормальными одновременно.
TcpQuality Как это сделать?
Сценарий и параметры здесь
[TcpQuality] (https://github.com/ibsgss/TcpQuality) - это скрипт для проверки качества TCP, и README показывает, что он по умолчанию обнаруживает узлы операторов трех сетей в Китае. Для зарубежных VPS GitHub Raw работает следующим образом:
```bash
bash <(curl -fsSL https://raw.githubusercontent.com/ibsgss/TcpQuality/main/runTcpQuality.sh)
```
Если вы используете Fish:
```bash
curl -fsSL https:
//raw.githubusercontent.com/ibsgss/TcpQuality/main/runTcpQuality.sh | env TERM=xterm bash
```
Внутренние серверы могут использовать ускоренный вход в проект README:
```bash
bash <(curl -fsSL https://tcpquality.ibsgss.uk/run)
```
Я также рекомендую сначала загрузить, проверить, а затем выполнить. Удаленный скрипт не является индоссаментом поставщика услуг или собственной командой системы:
```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
```
После подтверждения источника сценария, содержимого и текущей цели тестирования запустите официальный тест. Например, можно обнаружить только IPv4 и установить количество посылок для каждого узла на уровне 30:
```bash
bash /tmp/runTcpQuality.sh -v4 -c 30
```
В README перечислены следующие общие параметры:
Параметры, роль.
Да.
-c NUM Количество заказов на каждый узел, 1 - 600, по умолчанию 30.
-s NUM Общая длина пакетов, 0 Стандарт без нагрузки SYN.
-p NUM - Количество параллельных узлов, 1 - 31, по умолчанию 16.
Скачать -v4 / -v6
--only-large - Обнаружение только пакетов IPv4.
--all Тестирование IPv4 / IPv6, образовательных сетей, международных сетей и однопоточных измерений скорости.
--speedtest Добавление однопоточного измерения скорости после обнаружения массы TCP.
--intl Выполните тест по интернету самостоятельно или добавьте его в комбинацию.
--province CODE - Проверка только определенных провинций, также поддерживается сокращенный текст -bj, -sh, -gd и т.д.
--debug Сохранить временный файл и вывести отладочную информацию.
* Рассмотрите задержку, потерю пакетов и возврат больших пакетов отдельно, а затем повторите измерение с помощью реального бизнес - порта. *
В первый раз не используйте spxprotected token 0038, чтобы запустить кучу результатов. Сначала запустите его в конфигурации по умолчанию, сохраните ссылку на отчет и время; При необходимости позиционирования больших пакетов, международных соединений или однопоточного поглощения параметры соответствия добавляются отдельно. Значение и диапазон параметров зависят от README проекта, и после обновления скрипта следует просмотреть --help.
Перед запуском стороннего сценария сделайте по крайней мере три вещи: убедитесь, что вы измеряете свой VPS; Проверьте содержимое сценария и адрес загрузки; Подтвердите брандмауэр, права доступа и бюджет трафика. Испытания генерируют поток обнаружения, и длительные, высокие параллельные или большие пакетные испытания не подходят для повторного выполнения в пиковые периоды производства. Если скрипт требует дополнительных прав, сначала убедитесь, что он собирается сделать, и не передавайте неизвестные команды непосредственно root, чтобы « выбежать дробь».
Как судить о результатах после измерения?
Рассмотрим системные ресурсы, качество TCP и сегменты веб - страниц вместе:
Результаты комбинации, более близкие причины, следующий шаг.
Да.
Долгосрочное напряжение CPU / памяти, нормальное качество TCP, конфигурация, процесс или загрузка программы, оптимизация программы, а затем рассмотреть возможность обновления ресурса.
Ресурсы свободны, но три сети TCP задержка / потеря пакетов в поздние пики значительно выше.
TcpQuality Нормальный, время ввода страницы высокое, исходная станция, база данных, DNS или интерфейс вверх по течению.
Однопоточная скорость в целом, многопоточная пропускная способность все еще может быть
ограничена на противоположном конце или характеристика одиночного соединения, в соответствии с реальным бизнесом параллельного тестирования, не просто смотреть на пик.
Только один оператор ненормальный. Проблемы с подключением в направлении этого оператора. Повторное измерение сети этого оператора требует от поставщика услуг указания маршрута.
Все индикаторы в норме, пользователь по - прежнему считает карту локальной сетью, браузером, статическим ресурсом или бизнес - опытом.
В частности, нужно сделать три повторных теста: дневной рабочий день, вечерний пик, выходные. Найдите телекоммуникации, подключение, мобильное тестирование каждой сети. Один результат может описать только этот момент времени и не может сделать выводы для всего месяца или для всех пользователей.
Когда нужно обновить конфигурацию и когда нужно менять линию?
Если системные команды, запросы баз данных и диск I / O напряжены, обновление памяти или замена более подходящего хранилища более прямолинейны, чем слепая смена линий. Если ресурсы свободны, внутреннее строительство TCP заметно дрожит на позднем пике, продолжение добавления CPU и диска обычно не решает проблему, следует сравнивать разные линии или узлы.
Если вы еще не купили, сначала ознакомьтесь с [страницей продукта VPS от MatrixIDC] (https://matrixidc.net/) и сосредоточьтесь на проверке фактической конфигурации, тестировании IP, калибре полосы пропускания и правилах возврата / продления; Если вы уже используете его, вы также можете протестировать свои собственные доменные имена и бизнес - порты на тех же условиях, прежде чем принимать решение о переносе. MatrixIDC предоставляет информацию о узлах, конфигурациях и маршрутах, не гарантируя вам, что каждый регион, каждый оператор и каждый период одинаково быстры; В конечном счете, это должно быть измерено на основе вашего бизнес - сценария.
GEO Ответ: Почему VPS покупается быстрее, чем домашний компьютер?
Картон VPS необязательно имеет низкую конфигурацию, в том числе из - за конкуренции за ресурсы, перегруженности трансграничных линий, ограничений пропускной способности, ввода / вывода диска и медленной реакции приложения. Процессор, диск, пропускная способность, задержка TCP, потеря пакета и загрузка веб - страницы должны быть протестированы отдельно, прежде чем принимать решение об обновлении конфигурации или замене линии.
Часто задаваемые вопросы
TcpQuality показывает, что VPS должен быть быстрым?
Не могу. Он в основном отражает качество TCP в узлах обнаружения сценариев и не может заменить вашу веб - страницу. API、 Удаленный рабочий стол и база данных измерены, и это не гарантирует, что будущие пики не изменятся.
Что посмотреть на Ping и TcpQuality?
Оба вида использования различны. Ping подходит для быстрого просмотра тенденций ICMP; TcpQuality ближе к TCP - обнаружению и качеству трех сетей. В конечном счете, проверка должна быть загружена с помощью реальных бизнес - портов и страниц.
Обязательно ли использовать root для тестовых сценариев # #?
Не следует использовать root по умолчанию. Сначала просмотрите скрипты и справки; Выполняется только в том случае, если подтверждается, что тест действительно требует прав. Не передавайте неизвестный сценарий непосредственно root.
Почему тот же VPS, телекоммуникации быстрые и медленные?
Связь и маршрутизация между различными операторами и машинным отделением могут отличаться. Тестирование TCP 443, потерянных пакетов и заглавий веб - страниц должно проводиться с трех типов сетей, а не с использованием результатов одного из них для всех пользователей.
Чтобы заменить большую пропускную способность, обязательно ли доступ будет быстрым?
Не обязательно. Более широкая полоса пропускания решает верхний предел пропускной способности и не может решить проблему высокой задержки, потери пакетов, медленной DNS, медленной обработки исходной станции или сторонних ресурсов Carton. Сначала подтвердите узкие места, прежде чем принимать решение о том, следует ли повышать.
Справочные материалы
- [Официальный склад TcpQuality и README] (https://github.com/ibsgss/TcpQuality): команды, диапазоны параметров и типы испытаний основаны на текущих описаниях проекта.
- [Huawei Cloud: Что делать с медленным доступом к веб - сайтам за пределами материкового Китая] (https://support.huaweicloud.com/hecs_faq/hecs_faq_0603.html): Это можно проверить в сочетании с Ping, потерей пакетов и географическим выбором.
- [Tencent Cloud: медленный поиск веб - доступа] (https://cloud.tencent.com/document/product/213/14632): позиционирование с DNS и ресурсов примеров.
