Технологии / Почему VPN тормозит: разбор по участкам

Почему VPN тормозит: разбор по участкам

Обновлено 30 августа 2026~45 мин чтения

«Тормозит» — это не поломка, а ощущение. За ним может стоять четыре совершенно разных причины, и лечатся они в разных местах.

Между вами и сайтом, который вы открываете, стоит длинная цепочка. Ваш телефон, вышка оператора, его сеть, международный стык, чужие сети за границей, и только в конце — сервер VPN. Сломаться может любое звено, а на выходе вы скажете одну и ту же фразу.

Дальше — по главе на участок: канал сервера, его железо и связность с Россией. В каждой два вопроса: что именно ломается и по какому признаку это видно со стороны.

1. Канал сервера

Начнём с простого: сколько мегабит сервер вообще может отдать.

В тарифе хостера обычно написано что-то вроде «порт 10 Гбит/с». Это характеристика их оборудования, а не обещание лично вам. Виртуальные серверы живут на общем железе и делят общий канал — поэтому важнее не цифра в тарифе, а то, как хостер этот канал между всеми делит. Способов ровно три, и каждый чувствуется по-своему.

1.1 Никак не делит

Хостер не ограничивает никого. Тогда одна шумная машина способна забрать почти весь канал, а остальным достаётся что осталось.

Плохо здесь не среднее число мегабит, а непредсказуемость: соседи меняются, и один и тот же сервер в понедельник даёт четыреста мегабит, а в пятницу вечером — сорок. Заметно это сразу и по всему: падает скорость, растут задержки, появляются потери.

1.2 Шейпинг: очередь

Шейпер — это ограничитель с очередью. Он ничего не выбрасывает: лишние пакеты просто ждут отправки.

Пока очередь короткая, всё хорошо. Как только она набивается, каждый пакет проводит в ней время — и это время добавляется к задержке. Именно так выглядит знакомое «скорость вроде нормальная, а видео буферится».

1.3 Полисинг: ножницы

Полисер очередь не держит. Превысил лимит — пакет выброшен, и отправитель узнает об этом, только когда ответ не придёт.

Ограничение одно и то же, а чувствуется по-разному — по этому и различают.

Казалось бы, теперь всё просто: увидели рост задержки — шейпер, увидели потери — полисер. На практике так не выходит.

1.4 Почему пинг и потери молчат, даже когда канал режут

Резонный вопрос: если канал действительно режут, мы же должны это увидеть? Должны — но только если смотреть тем, что нагружает канал. А пинг его не нагружает.

Ограничитель — не шлагбаум, который закрыт всегда. Он срабатывает только на превышении: пока трафик ниже лимита, он его не трогает вовсе.

Теперь посчитаем, сколько «весит» проверка пингом. Двадцать пакетов в секунду по 64 байта — это около десяти килобит в секунду. Лимит, который мы ищем, — сто мегабит. Проверка идёт в десять тысяч раз ниже планки: до неё просто не дотягивается, и ограничителю нечего резать.

С потерями то же самое: полисер выбрасывает лишние пакеты, а пинговые лишними не бывают. Очереди он не создаёт, значит и задержка не растёт. Вот и получается сервер, у которого ноль потерь, идеально ровный пинг — и при этом людям не хватает скорости.

1.5 Почему быстрая проверка скорости обманывает

С замером скорости история другая: он-то планку превышает. Но его спасает корзина всплеска.

Ограничитель обычно устроен так: небольшой запас разрешено потратить сразу на любой скорости, а дальше — только по лимиту. Замер «скачаем файл и посмотрим» длится секунду-две и целиком укладывается в этот запас.

Отсюда правило, которое стоило нам нескольких неверных выводов: короткий замер отвечает на вопрос «трафик вообще проходит?», а не «сколько достанется человеку». На второй вопрос честно отвечают только счётчики самого сервера, накопленные за часы.

1.6 Ограничение включается не сразу — и приёмка его не застаёт

Есть и вторая причина, по которой при проверке новой машины всё выглядит прекрасно.

Хостеры редко режут по мгновенной скорости. Обычно смотрят на устойчивое превышение: разовый всплеск терпят, а ограничение включают, только если сервер держит скорость выше положенной несколько минут — у части площадок счёт идёт от десяти минут и больше.

Приёмка новой машины длится секунды. То есть она проверяет сервер ровно в том режиме, в котором ограничение ещё не включилось.

1.7 Два способа ограничить: по скорости или по объёму

До сих пор речь шла об ограничении скорости. Но у хостеров есть и второй подход, и ведёт он себя совсем иначе.

Лимит скорости — потолок в мегабитах, действует всегда. Быстрее нельзя, но и хуже со временем не становится.

Лимит объёма — сколько всего можно передать за месяц. Пока пакет не исчерпан, скорость полная; как только он закончился, включается ограничение — скорость режут (иногда до совсем символической) либо просят доплатить.

Второй вариант коварнее именно тем, что первые недели ничем себя не проявляет.

Отсюда простое правило приёмки: у хостера нужно узнавать обе цифры — и какая скорость, и сколько трафика включено. «Безлимитный канал 1 Гбит/с» без второй цифры не означает ничего: за месяц по такому каналу можно передать сотни терабайт, и почти никто столько не отдаёт бесплатно.

1.8 Замер показывает пол, а не потолок

Второе свойство любой проверки скорости: она занимает канал на несколько секунд и записывает, сколько получилось. Это нижняя граница, а не верхняя. Занизить её может что угодно: другие люди на том же сервере, длинная дорога до точки замера, особенности TCP.

Пример из практики. Слева — что показал короткий замер, справа — какой трафик тот же сервер реально пропускал в течение суток:

Разница видна сразу: либо замер совпадает с реальностью — и тогда канал действительно узкий, либо расходится в разы — и тогда ограничена средняя скорость, а сам порт свободен.

Разница не теоретическая. В первом случае вопрос к хостеру уместен, во втором он покажет график со всплесками и будет прав.

1.9 Что тогда работает

Раз проверкам верить нельзя, признак строится на собственном трафике сервера — том, что он реально пропустил за час, за сутки, за неделю. Ограничитель рисует прямую линию; живой спрос прямую не рисует никогда.

Дальше — арифметика: сравниваем, насколько трафик «прижат» к одному и тому же значению, и проверяем, что сервер вообще умеет быстрее (например, на прошлой неделе он проходил заметно больше). Если и то и другое сходится, а людей на сервере много — это упор в потолок, а не тихий вечер.

Есть и обратная ловушка. Проверять ровность за целый час мало: одного всплеска внутри часа хватает, чтобы «полка» перестала быть заметной.

Поэтому рядом стоит вторая проверка на коротком окне — не «ровный ли час», а насколько разбросаны значения. У живого спроса разброс есть всегда, у ограничителя он практически нулевой. Между этими двумя состояниями на практике остаётся хороший запас, так что перепутать сложно.

1.10 Когда ограничение начинает мешать

Справедливый вопрос: если канал ограничен, но пользователи этого не замечают — кому от этого плохо?

Никому — пока пользователи не упираются в это ограничение.

Например, сервер может иметь лимит в 1 Гбит/с и при этом десятки пользователей. Если в каждый момент времени им достаточно 100–200 Мбит/с суммарно, ограничение никак себя не проявляет.

Проблема начинается, когда реальный спрос приближается к потолку канала. Тогда на графике появляется характерная картина: трафик долго держится примерно на одном максимальном значении, а при росте нагрузки скорость уже не увеличивается.

В этот момент важно смотреть не только на сам лимит, но и на то, сколько пользователей одновременно делят доступную полосу.

Например, если сервер упёрся в ограничение 100 Мбит/с, а одновременно через него проходит большой объём трафика от 250 пользователей, это в среднем всего около 0,4 Мбит/с на пользователя, если мысленно разделить доступную полосу поровну.

Этого недостаточно даже для стабильного просмотра видео в 360p.

Но это не означает, что каждый из 250 пользователей действительно получает 0,4 Мбит/с. Распределение трафика неравномерное: кто-то в этот момент ничего не передаёт, кто-то открывает страницу, а кто-то смотрит видео.

Поэтому такое деление имеет смысл только как грубая оценка того, насколько тесно серверу становится при текущей нагрузке.

Если сервер не упирается в потолок, делить его пропускную способность на количество подключённых пользователей бессмысленно: большинство из них в конкретный момент практически не потребляет трафик.

Именно поэтому нас интересует не сам факт наличия лимита, а сочетание трёх факторов: величина ограничения, реальная нагрузка и количество одновременно активных пользователей.

Так технический факт «канал ограничен 100 Мбит/с» превращается в понятный вывод: если сервер постоянно упирается в этот потолок, пользователям начинает не хватать доступной полосы — и это уже может проявляться в виде просадок скорости и буферизации видео.

1.11 Как локализовать проблему

Одного измерения недостаточно, чтобы понять, где находится проблема. Замер на самом сервере показывает, что происходит с его собственным каналом, а проверка из России — что происходит на всём пути от пользователя до сервера.

По отдельности результаты могут быть неоднозначными. Но если сопоставить несколько измерений, становится гораздо проще понять, где именно искать причину.

Важно: эта таблица не позволяет автоматически определить виновника. Каждый признак нужно сопоставлять с другими измерениями и проверять в динамике.

Если измерение устарело, прошло некорректно или не подтверждается другими тестами, мы вообще не используем его для вывода. Лучше временно оставить причину неизвестной, чем назначить виноватого на основании одного неудачного замера.

1.12 Что смотреть: канал сервера

Главное, о чём эта глава: по одному показателю вывод не делается. Ограничение канала видно только по совокупности, и проверять её надо по порядку.

Шаг 1. Есть ли полка. Смотрим трафик за час и за сутки по счётчикам интерфейса (/proc/net/dev, node_exporter), отдельно приём и отдачу.

• живой спрос даёт рваную кривую: пики, провалы, ночью почти ноль;
• ограничитель даёт линию: трафик часами держится у одного значения и выше не идёт.

Если линии нет — дальше можно не смотреть, машина в канал не упирается.

Шаг 2. Умеет ли машина быстрее. Полка сама по себе ещё ничего не значит: может, столько и просят. Ищем в истории случаи, когда через машину проходило заметно больше: пик за неделю против нынешнего уровня.

• проходило в разы больше — значит порт шире, и ограничена именно средняя скорость;
• никогда не проходило больше — либо канал действительно такой, либо машину режут всё время, и история этого уже не покажет. Тогда нужен активный замер: скачать файл в 4–8 потоков и посмотреть, получится ли пробить уровень полки.

Шаг 3. Не кончился ли пакет трафика. Если у тарифа есть месячный объём, сверить израсходованное с включённым. Резкий обрыв в середине месяца и ровная низкая полка после него — это не поломка, а исчерпанный пакет.

Когда идти к хостеру. Разговор имеет смысл, если полка есть, а всплесков выше неё — нет: тогда порт действительно срезан. Если же машина регулярно выдаёт кратно больше полки, хостер покажет этот график и будет прав: ограничена средняя скорость, и решается это сменой тарифа или площадки, а не письмом в поддержку.

2. Железо сервера

Второй участок — сама машина. И здесь главное разочарование: число ядер в тарифе почти ничего не обещает.

Сервер с четырьмя ядрами старого процессора и сервер с двумя ядрами свежего — машины разного класса, и второй нередко везёт VPN лучше.

2.1 Кухня с поварами

Грубо говоря, скорость ядра — это «сколько работы за такт» помноженное на «сколько тактов в секунду». Современное ядро на трёх гигагерцах спокойно обгоняет старое на трёх с половиной: за такт оно успевает больше. А максимальная частота из описания («до 5,7 ГГц») — это верхняя отметка на короткое время, а не режим постоянной работы.

2.2 Десктопный процессор обгоняет серверный

Звучит странно, но на нашей работе это так. Мы измерили, во что обходится один сетевой пакет на каждом процессоре парка — не в синтетике, а на живом трафике.

Между лучшим и худшим — разница в пять с половиной раз. Одна и та же нагрузка на первом даёт десять процентов загрузки, на последнем — пятьдесят пять.

Причина не в маркетинге. Обработка пакетов упирается в частоту и скорость одного потока, а не в количество ядер. От сорокавосьмиядерного серверного процессора виртуальной машине достаётся пара ядер по 2,75 ГГц, а настольный отдаёт свои 4,3 ГГц целиком. Отдельная проверка, гоняющая только пакеты, показала то же самое: 2,7 миллиона пакетов на ядро против 1,4 миллиона.

Старые серверные Intel в этом списке — самое слабое место: они впятеро дороже по пакету, и вдобавок несут полный набор защит от аппаратных уязвимостей (девять включённых против трёх у новых AMD). Каждая стоит времени на системных вызовах, а у прокси их миллионы в секунду.

2.3 Виртуальное ядро — не ваше ядро

У виртуального сервера есть отдельная беда: ядро в тарифе не значит, что оно ваше целиком. Соседи по физической машине конкурируют за то же железо, и гипервизор может просто не дать вам процессорное время.

Изнутри это не выглядит как нагрузка — просто всё идёт медленнее.

Отсюда правило: смотреть надо не на красивое число ядер в тарифе, а на цепочку класс процессора → скорость одного ядра → сколько ядер → сколько времени отнимают соседи → сколько машина реально пропускает под нашей нагрузкой.

И ещё одно наблюдение, которое стоит держать в голове: у VPN-сервера почти всегда первым упирается процессор, а не канал. Рекорды по трафику, которые мы видели, — это несколько процентов от гигабитного порта.

2.4 Что смотреть: железо сервера

Отдельно, при приёмке машины: openssl speed -evp aes-256-gcm — но читать это надо как «какого класса железо», а не «сколько машина потянет». Шифрование у нас не узкое место, и по нему сравнивать серверы бессмысленно (см. 2.1).

Порядок действий. Сначала загрузка и steal: если steal большой, дальше можно не копать — время у машины отнимают соседи. Если загрузка высокая, а steal нулевой, смотреть, чем она занята: пользовательской работой или softirq. И уже потом — память, интерфейс и conntrack, они ломаются реже.

Самое важное — это так называемая связность

Чтобы понять, от чего зависит качество VPN, сначала разберёмся, что происходит с трафиком на пути от вашего устройства до VPN-сервера.

Возьмём простой пример: вы подключились к мобильной сети МТС, включили наш VPN и открыли ChatGPT.

Упрощённо путь выглядит так:

устройство → базовая станция → сеть МТС → магистраль → международный стык → зарубежная сеть → VPN-сервер → ChatGPT

Но за этими несколькими словами скрывается довольно много оборудования.

1. Устройство → базовая станция

Ваш телефон передаёт данные по радиоканалу на базовую станцию мобильного оператора.

На этом этапе трафик ещё находится внутри инфраструктуры мобильного оператора.

2. Базовая станция → региональная сеть

От базовой станции трафик попадает в транспортную сеть оператора. Обычно для этого используется оптоволоконная инфраструктура, хотя на отдельных участках могут применяться и другие технологии.

Дальше трафик проходит через различные узлы сети МТС.

Региональный узел — это физическая площадка, где размещается сетевое оборудование оператора: маршрутизаторы, коммутаторы, оптическое и транспортное оборудование.

Это может быть отдельное здание оператора, узел связи или часть дата-центра.

Упрощённо:

📡 Базовые станции
       ↓
   транспортная сеть
       ↓
┌─────────────────────┐
│ Региональный узел   │
│                     │
│ маршрутизаторы      │
│ коммутаторы         │
│ оптическое оборудование │
└─────────────────────┘
       ↓
   дальше по сети

Важно понимать, что это не один «главный компьютер», который решает судьбу каждого пакета. Маршрутизация распределена между множеством сетевых устройств.

3. Магистральная сеть и магистральные узлы

Если трафику нужно попасть из одного региона в другой или к международному выходу, он может пройти по магистральной сети оператора.

Магистраль — это высокопроизводительная транспортная инфраструктура, которая соединяет крупные узлы сети.

Например:

Региональный узел
       ↓
      100G
       ↓
Магистральный узел
       ↓
      400G
       ↓
Магистральный узел
       ↓
Международный выход

Магистральный узел физически выглядит примерно так же, как и другой узел связи: это площадка со стойками, маршрутизаторами, коммутаторами и транспортным оборудованием. Отличие в его роли и масштабе: через него проходят крупные потоки трафика между частями сети.

При этом не существует обязательного правила:

«регион → Москва → магистральный узел → зарубежье».

Конкретный путь зависит от топологии сети оператора и используемой маршрутизации.

4. Международный стык

Здесь важно не путать магистраль и международный стык.

Магистраль — это сама транспортная сеть.

Международный стык — это соединение между сетями разных операторов или сетями разных стран.

Например:

Российский оператор
        │
        │ собственная / арендованная
        │ международная линия
        ↓
┌──────────────────────────┐
│  Площадка / дата-центр   │
│                          │
│ [маршрутизатор РФ]       │
│          │               │
│       оптика             │
│          │               │
│ [маршрутизатор зарубежного│
│        оператора]        │
└──────────────────────────┘
        ↓
Зарубежная сеть

Физически это не обязательно выглядит как какой-то специальный «международный сервер».

В простейшем случае это два маршрутизатора разных операторов, соединённых оптическим каналом.

Такое соединение может находиться внутри дата-центра, на телекоммуникационной площадке или быть частью трансграничной волоконно-оптической линии.

На одном таком объекте может находиться множество разных стыков между различными операторами.

Именно здесь российский трафик может перейти из сети российского оператора в сеть зарубежного оператора.

5. Дальше трафик движется по зарубежным сетям

После международного стыка трафик оказывается в сети зарубежного оператора.

Дальше происходит примерно то же самое:

Международный стык
       ↓
Зарубежный оператор
       ↓
магистральная сеть
       ↓
другой оператор
       ↓
сеть хостера
       ↓
🖥 VPN-сервер

Причём между российским оператором и нашим VPN-сервером может находиться несколько разных автономных систем и транзитных операторов.

И вот здесь возникает главный вопрос:

откуда каждый из этих операторов знает, куда отправлять пакет?

6. Здесь появляется BGP

Каждое сетевое устройство не хранит в памяти «весь Интернет» в виде списка всех возможных физических дорог.

Внутри сетей операторы используют протоколы маршрутизации, которые позволяют сетевому оборудованию определить, куда отправлять трафик.

А когда речь идёт о взаимодействии разных автономных систем (AS), одним из главных протоколов становится BGP — Border Gateway Protocol.

Упрощённо можно представить это так:

AS МТС
   ↓
AS транзитного оператора
   ↓
AS другого оператора
   ↓
AS хостера
   ↓
VPN-сервер

Каждая сеть сообщает соседним сетям, какие IP-префиксы она может достичь. На основании полученной информации и своей политики маршрутизации сеть выбирает подходящий маршрут.

Поэтому путь от телефона до VPN-сервера — это не просто физическая цепочка кабелей.

Это одновременно:

физическая инфраструктура + маршрутизаторы + транспортные сети + международные стыки + маршрутизация между автономными системами.

И качество каждого из этих участков может непосредственно влиять на то, насколько быстро и стабильно будет работать VPN.

Как мы проверяем связность с Россией

Именно поэтому при заказе нового сервера мы смотрим не только на его процессор, канал и расположение.

Нас интересует ещё один важный вопрос:

Насколько хорошо этот сервер связан с российскими сетями?

Потому что сервер может находиться, например, в Германии, иметь мощный процессор и канал 10 Гбит/с, но при этом иметь плохой маршрут до пользователей из России.

Условно:

Россия → оператор → магистраль → ??? → сервер

Нас интересует, что находится на месте ???: через каких операторов и сети проходит трафик, какая задержка получается, есть ли потери и насколько стабилен маршрут.

Поэтому перед тем, как принять сервер в нашу инфраструктуру, мы проверяем его связь с несколькими российскими сетями.

Проверяем маршрут

С самого сервера запускаем трассировку до нескольких независимых российских сетей.

Например:

VPN-сервер
    ↓
оператор хостинга
    ↓
транзитный оператор
    ↓
российская магистраль
    ↓
российская сеть

Так мы видим не только конечную задержку, но и через какие автономные системы проходит маршрут.

Это важно, потому что два сервера в одной стране могут иметь совершенно разную связность:

Сервер A → оператор 1 → оператор 2 → Россия
Сервер B → оператор 3 → оператор 4 → оператор 5 → Россия

Географически они могут находиться рядом, но сетевой путь до России будет совершенно разным.

У трассировки есть одна ловушка, о которой стоит знать заранее: потери на промежуточном узле почти никогда не означают потерю трафика.

Что мы измеряем

Для каждого маршрута смотрим три основных показателя:

RTT — задержка туда и обратно.

Packet Loss — процент потерянных пакетов.

Jitter (mdev) — насколько сильно меняется задержка между отдельными пакетами.

Например:

Сервер A
RTT:     42 мс
Loss:     0%
Jitter:  0.3 мс

Сервер B
RTT:     45 мс
Loss:     0%
Jitter:  8.7 мс

На первый взгляд оба сервера имеют практически одинаковый пинг.

Но второй маршрут значительно менее стабильный: задержка гуляет намного сильнее. Под реальной нагрузкой это может проявляться как рывки, просадки скорости и нестабильная работа TCP-соединений.

Почему мы проверяем несколько российских сетей

Одна точка назначения может дать неправильное представление о маршруте.

Например, ICMP-пакеты до одного оператора могут фильтроваться или обрабатываться с низким приоритетом. Тогда мы увидим потери, хотя с реальным каналом всё нормально.

Поэтому мы проверяем несколько независимых сетей.

При этом для оценки задержки используем одну и ту же контрольную точку для всех серверов — иначе получится нечестное сравнение: один сервер мы будем сравнивать с Москвой, а другой, например, с Владивостоком.

Для потерь и стабильности маршрута, наоборот, полезно посмотреть несколько целей и убедиться, что проблема воспроизводится независимо от конкретной сети.

Проверяем не только маршрут, но и реальную полосу

Низкий пинг ещё не означает хорошую связность.

Поэтому отдельно проверяем скорость передачи данных между сервером и российскими точками.

Для этого используем iperf3 и смотрим реальную пропускную способность.

Получается уже более полная картина:

Связность с Россией

├── маршрут
│   ├── через каких операторов идёт
│   ├── RTT
│   ├── потери
│   └── jitter
│
└── пропускная способность
    └── реальная скорость передачи данных

Отдельно — задержка под нагрузкой

Вхолостую задержка почти всегда прекрасная. Интереснее другое: что с ней происходит, пока канал занят. Если на пути стоит ограничитель с очередью, она набивается именно в этот момент — видео не успевает наполнить буфер и встаёт, хотя «пинг нормальный».

Поэтому пинг снимается во время загрузки, а не отдельно от неё.

Почему низкий пинг не гарантирует хороший VPN

Это один из самых важных моментов.

Можно получить:

RTT: 25 мс
Loss: 0%

и при этом иметь практически неработающий VPN.

Например, ICMP с сервера в Россию может проходить нормально, а входящие TCP-соединения из России на этот IP могут блокироваться или теряться.

Получается:

Сервер → Россия
   ICMP ✓
   TCP  ✓

Россия → Сервер
   ICMP ✓
   TCP  ✗

Обычный ping этого не покажет.

Поэтому отдельно нужно проверять доступность сервера именно из России, то есть реальное подключение к VPN-ноде с российской стороны.

Есть и обратная проблема

Даже если соединение устанавливается, пинг ничего не говорит о доступной полосе.

Например:

RTT:       40 мс
Loss:       0%
Speed:     50 Мбит/с

и:

RTT:       40 мс
Loss:       0%
Speed:      2 Гбит/с

Для пользователя это будут совершенно разные серверы.

Поэтому связность — это не один показатель.

Нам важно одновременно понимать:

куда идёт маршрут → насколько он стабильный → сколько по нему реально можно передать → устанавливаются ли соединения из России.

И наконец — проверка изнутри не заменяет проверку снаружи

Есть принципиальная разница между двумя измерениями:

1. Сервер → Россия

2. Россия → сервер

Первое показывает, насколько хорошо сам сервер может достичь российских сетей.

Второе показывает, насколько российский пользователь может достичь сервера.

Эти направления могут работать совершенно по-разному.

Поэтому после установки сервера мы дополнительно проверяем его с российской стороны, используя реальное подключение и передачу данных через VPN.

Именно это позволяет увидеть проблемы, которые невозможно обнаружить обычным ping с самой ноды.

В итоге при выборе сервера мы оцениваем не просто:

«Сколько миллисекунд до России?»

а гораздо более важный вопрос:

«Насколько хорошо этот сервер связан с российскими сетями и способен стабильно передавать через них большой объём трафика?»

Что смотреть: дорога до пользователя

Третий чек-лист. Здесь всё меряется не с сервера, а из сети пользователя — проверка с самой машины отвечает на другой вопрос и не заменяет эту.

Порядок действий. Сначала «доезжает ли вообще»: соединение и потери. Если доезжает — скорость в один и в восемь потоков. Если скорость низкая в обоих случаях, а канал у машины широкий — дело в дороге, и хостер тут не поможет. Если задержка под нагрузкой выросла — на пути очередь, и это уже вопрос к хостеру.

Чем и на что смотрят

Как этим пользоваться. Каждая глава заканчивается своим чек-листом: канал, железо, дорога. Идти по ним стоит сверху вниз — от самого дешёвого измерения к самому долгому:

1. Железо — загрузка и steal. Меряется за секунды и сразу отсекает половину случаев.
2. Канал — счётчики за час и сутки: есть ли полка и есть ли запас.
3. Дорога — проверка из сети пользователя: доезжает ли, с какой скоростью, что с задержкой под нагрузкой.

И одно правило поверх всех трёх: вывод делается там, где сошлись два независимых источника. Один прибор всегда допускает несколько объяснений.

Ни один из них не отвечает на вопрос целиком — и в этом главная мысль всего текста. «Быстрый сервер» это не одно число, а совпадение нескольких: широкий канал, свободный процессор, короткая и ровная дорога до вас и работающее соединение из вашей сети.