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

Различия между ядрами, потоками и временем процессора

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

В режиме виртуального хостинга несколько учетных записей совместно используют аппаратное обеспечение одного сервера. Тарифный план может ограничивать количество процессорного времени, которое процессы одной учетной записи могут потреблять в течение определенного периода. Это Бюджет времени ЦП это не то же самое, что обязательство по эксклюзивному использованию физического ядра. Linux-cgroups являются одной из возможных технических основ для таких ограничений, но не единственной возможной реализацией.

Если в тарифе указано, например, „один vCore“ или „100 процентов ЦП“, тебе следует проверить определение, данное провайдером. Данное указание может означать лимит вычислительного времени без постоянного резервирования конкретного ядра. Кроме того, из общего количества ядер хост-сервера нельзя определить, какой объём вычислительной мощности может фактически использовать одновременно отдельная учетная запись.

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

Ограничение ресурсов и изоляция безопасности выполняют разные задачи: ограничение регулирует потребление, тогда как изоляция призвана ограничивать доступ между средами. Классификация CloudLinux Site Isolation и CageFS объясняет соответствующие механизмы безопасности; само по себе это не влечет за собой конкретного распределения ресурсов ЦП.

Почему одного только ГГц недостаточно

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

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

Одним из примеров ограниченной технической спецификации является процессор AMD EPYC 4564P: для этой модели AMD указывает 16 ядер, 32 потока, базовую тактовую частоту 4,5 ГГц и максимальную тактовую частоту в режиме Boost до 5,7 ГГц. Эти данные описывают характеристики процессора, а не производительность конкретного тарифного плана хостинга.

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

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

Запросы PHP и параллельная обработка

При типичном синхронном запросе PHP-рабочий процесс обрабатывает отдельные этапы своей работы в основном последовательно. Более быстрый процессор может сократить эту часть, если она действительно требует интенсивных вычислений. Если же рабочий процесс в основном ожидает ответа от базы данных или внешнего сервиса, польза от более высокой производительности процессора в отношении этого времени ожидания будет ограниченной.

Формулировка запроса php одноядерный поэтому это не означает, что весь веб-сайт может использовать только один ядро. Несколько запросов могут обрабатываться параллельно несколькими рабочими процессами; веб-сервер и база данных также могут работать одновременно. Решающим фактором является то, насколько доступные ресурсы и соответствующая конфигурация позволяют осуществлять такую параллельную работу.

В случае использования PHP-FPM ограничение составляет pm.max_children количество запросов, одновременно обрабатываемых одним пулом. Если этот предел достигнут, дополнительные запросы не могут быть немедленно обработаны другим рабочим процессом из этого пула. Однако этот предел не определяет, сколько посетителей в целом может пользоваться сайтом.

Die Управление процессами PHP-FPM поддерживает три режима работы: static поддерживает фиксированное количество рабочих процессов. dynamic адаптирует их количество в соответствии со спросом на основе настроек; ondemand запускает рабочий процесс по мере необходимости. Таким образом, выбранный режим работы также определяет, когда процессы будут готовы к работе или будут запущены заново.

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

Квота ЦП при параллельной нагрузке

A Квота ЦП определяет, сколько вычислительного времени может потреблять группа процессов в течение определенного периода. В Linux cgroup v2 описывает cpu.max данный бюджет и соответствующий период. Таким образом, квота не резервирует автоматически эксклюзивное физическое ядро: она ограничивает общее доступное время процессора для группы.

Наглядный расчетный пример, не основанный на измерениях: группа получает 100 миллисекунд времени ЦП на каждый 100-миллисекундный период. Это в среднем соответствует времени вычислений полностью загруженного логического процессора. Если два процесса выполняют вычисления одновременно на двух доступных логических процессорах, теоретически они могут исчерпать общий бюджет примерно через 50 миллисекунд реального времени.

Если бюджет исчерпан, скорость выполнения процессов может быть снижена до следующего периода. Таким образом, оба рабочих процесса не располагают собственным бюджетом в 100 миллисекунд каждый. Будут ли они фактически работать параллельно и когда именно — зависит, в частности, от планировщика, доступных процессоров и их поведения; данный пример не позволяет предсказать конкретное время отклика.

Для исследования cgroup v2 в cpu.stat в том числе счетчики для Дросселирование готовы. Если они увеличиваются во время типичной фазы нагрузки, это свидетельствует об исчерпании квоты. Однако однократное показание счетчика ещё не позволяет определить, какой именно запрос был затронут, или существуют ли помимо этого другие узкие места.

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

CMS, интернет-магазин и фоновые задания

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

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

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

Поэтому большое количество одновременных запросов на оформление заказа может создавать более высокую нагрузку на рабочие процессы или ресурсы ЦП, чем такое же количество запросов на страницы из кэша. Одно лишь количество посетителей не отражает эту нагрузку: решающее значение имеет то, какие конечные точки запрашиваются одновременно и как часто используется кэш. Кроме того, в PHP-FPM настройка пула ограничивает pm.max_children количество одновременно обрабатываемых запросов.

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

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

Сравнение наблюдений и узких мест

Медленный ответ сам по себе ещё не указывает на причину. В приведённом ниже обзоре типичные наблюдения сопоставляются с проверяемыми возможными причинами. В частности, в нём учитываются ограничения по времени работы ЦП, ограниченное количество рабочих процессов в PHP-FPM, а также разница между сохраненным кодом PHP и уже сгенерированным ответом.

Каждая строка таблицы представляет собой Гипотеза, а не готовый диагноз. Медленные ответы при параллельной обработке могут, например, совпадать с ограничением производительности ЦП, но также могут быть вызваны занятыми рабочими процессами или ожиданием ответа от базы данных. Поэтому, по возможности, проверяйте несколько сигналов одновременно и для одной и той же рабочей нагрузки, а не делайте выводы о необходимости смены тарифа на основании одного-единственного симптома.

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

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

Что касается кэша, стоит также провести концептуальное разграничение: OPcache сохраняет скомпилированный код PHP и тем самым позволяет избежать повторной компиляции. Кэш страниц, напротив, хранит уже сгенерированный ответ. Таким образом, быстрое попадание в кэш не доказывает ни того, что динамические запросы располагают достаточным ресурсом процессора, ни того, что OPcache заменяет логику приложения.

Выявление ограничений и времени ожидания

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

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

При параллельной нагрузке проверьте, загружены ли доступные рабочие процессы и растут ли счетчики предельных значений. В PHP-FPM ограничение составляет pm.max_children количество запросов, одновременно обрабатываемых пулом; возможность просмотра этого значения или показателя загрузки зависит от тарифного плана. Системы с Linux cgroup v2 могут в cpu.stat в том числе отображать счетчик ограничения. Увеличение показателя счетчика является поводом для более тщательной проверки бюджета ЦП и периода измерения.

Если SSH и соответствующий файл доступны, то cat /proc/self/cgroup принадлежность вызывающего процесса к cgroup. Из этого не следует, что веб-запросы выполняются в той же группе. Уточните пути, права доступа и интерпретацию у провайдера; кроме того, коды ошибок нельзя однозначно соотнести с конкретным ограничением любой системы виртуального хостинга.

Проверить кэш и сравнить тарифы

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

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

От этого следует отличать OPcache: Он сохраняет скомпилированный код PHP, но не заменяет ни полный кэш страниц, ни выполнение логики приложения. Проверьте доступность и настройки в среде выполнения веб-приложений. CLI имеет собственную настройку OPcache; поэтому один лишь просмотр командной строки не подтверждает конфигурацию для веб-запросов.

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

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

Более быстрый процессор или больший бюджет?

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

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

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

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

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