Как измерить разницу в задержке между глобальной CDN и собственными узлами?

Как измерить разницу в задержке между глобальной CDN и собственными узлами?

Насколько может различаться задержка глобальной CDN и собственных узлов? Для зарубежного независимого сайта ответ нельзя определить по одному скриншоту результатов теста скорости. На одном и том же сайте изображения товаров могут быстро загружаться из кэша на узле CDN, тогда как запросы к интерфейсу для получения заявок всё ещё могут обращаться к исходному серверу через несколько континентов. Для полезного сравнения нужно разделить результаты по регионам, состоянию кэша и типам запросов, а затем оценить задержки в хвосте распределения, а не только сравнивать средние значения.

Сначала уточните, какие именно два маршрута сравниваются

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

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

Для объективного сравнения также необходимо унифицировать содержимое ресурсов, способ сжатия, версии протоколов и параметры безопасности. Если цель — сравнить практические варианты доставки контента, можно сохранить отдельные настройки оптимизации каждой стороны, но различия необходимо указать. Если же нужно определить влияние архитектуры, следует по возможности контролировать переменные. Эти два вида тестирования не следует объединять в один вывод.

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

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

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

Тестируйте отдельно попадания в кэш, промахи кэша и динамические запросы

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

Состояние кэша следует подтверждать по заголовкам ответа и журналам платформы. После промаха кэша на узле CDN запрос всё ещё может попасть в кэш верхнего уровня, поэтому «промах» не обязательно означает полное обращение к исходному серверу. Для тестирования холодного кэша можно использовать контролируемую очистку или отдельные тестовые объекты. Произвольное добавление параметров запроса не всегда эффективно: эти параметры могут игнорироваться при формировании ключа кэша или, наоборот, менять путь обработки в приложении.

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

Учитывайте время до первого байта, медленные запросы и сбои

Ping может помочь оценить сетевое время кругового обращения, но не заменяет тестирование по HTTPS. С помощью curl или панели сетевых запросов браузера можно записывать время DNS-разрешения, подключения, TLS-рукопожатия, получения первого байта и полное время отклика. Учтите, что несколько временных показателей curl отсчитываются от начала запроса и накапливаются, поэтому их нельзя просто складывать. При разборе отдельных этапов рассчитывайте разницу с учётом определения каждого поля и указывайте, использовалось ли повторно то же соединение.

В отчёте приводите P50, P95, размер выборки и долю сбоев отдельно по регионам, типам запросов и состоянию кэша. P50 отражает типичный пользовательский опыт, а P95 показывает более медленную часть запросов. При недостаточном объёме выборки не следует делать чрезмерные выводы по P99. Тайм-ауты и ошибки нельзя просто исключать: иначе нестабильное решение может показаться более быстрым.

Определите разницу в задержке единообразно: «время отклика собственного узла минус время отклика CDN». Положительное значение означает, что CDN быстрее. При этом сохраняйте исходные показатели обеих сторон. Общий результат можно взвешивать по объёму бизнес-трафика, но подробные данные по регионам необходимо сохранить, чтобы медленные запросы на основных рынках не скрывались за усреднением по другим регионам.

Применяйте результаты тестирования для оценки доставки контента сайтом

Когда узел расположен близко к пользователю и кэш срабатывает, преимущество CDN обычно проявляется сильнее. Если собственные узлы охватывают ключевые рынки и имеют хорошее сетевое подключение к операторам, разница может сократиться. Для динамических запросов результат зависит от маршрута к исходному серверу, повторного использования соединения и расположения серверной части; универсального достоверного значения в миллисекундах не существует.

Для платформ вроде 易营宝, объединяющих интеллектуальное создание сайтов, многоязычные сайты, SEO и зарубежную рекламу, оценка также должна охватывать реальные целевые страницы рекламных кампаний и путь отправки заявки. Более быстрая загрузка изображений не означает, что основной контент страницы появится раньше; сокращение времени до первого байта также не гарантирует, что сторонние скрипты перестанут замедлять страницу. Необходимо дополнительно оценивать показатели загрузки в браузере и проверять их с помощью мониторинга реальных пользователей.

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