В тарифах виртуального хостинга часто встречается понятная на первый взгляд характеристика: 1 сайт, 5 сайтов, 10 сайтов или вообще без ограничений. Кажется, что этого достаточно для выбора. Если тариф разрешает разместить десять сайтов, значит можно загрузить десять WordPress и спокойно работать.
На практике количество разрешенных сайтов и количество сайтов, которые будут нормально работать, — разные вещи.
Десять небольших визиток могут почти не создавать нагрузки. Один активно посещаемый интернет-магазин способен потреблять больше ресурсов, чем все они вместе. А два внешне одинаковых сайта на WordPress могут отличаться по нагрузке в несколько раз из-за темы, плагинов, кэширования и характера посетителей.
Поэтому вопрос лучше ставить немного иначе: не сколько сайтов хостер разрешает добавить в аккаунт, а сколько ваших сайтов смогут одновременно работать в пределах доступных ресурсов.
И здесь уже появляются CPU, оперативная память, PHP-процессы, базы данных, дисковое пространство, фоновые задачи и несколько менее очевидных ограничений.
Лимит количества сайтов показывает только одну границу тарифа
Начнем с самой цифры в тарифной таблице.
Если указано «до 10 сайтов», провайдер обычно разрешает подключить к аккаунту соответствующее количество отдельных проектов. Но это не обещание производительности десяти сайтов при любой нагрузке.
У аккаунта одновременно действуют другие ограничения.
Может быть ограничено процессорное время, доступная память, количество одновременно выполняющихся процессов, число подключений к базе, дисковые операции или другие ресурсы.
Все сайты внутри одного аккаунта в той или иной форме используют этот общий запас.
Представим два тарифа. Оба позволяют разместить десять сайтов. Первый рассчитан на небольшие проекты с умеренной нагрузкой. Второй предоставляет заметно больше вычислительных ресурсов. Формально количество сайтов одинаковое, но реальные возможности аккаунтов будут разными.
Поэтому строку «количество сайтов» нужно читать вместе с характеристиками производительности.
Десять сайтов-визиток и десять интернет-магазинов нельзя сравнивать
Самый простой пример показывает, почему невозможно назвать универсальное число сайтов для одного хостинга.
Допустим, у веб-мастера есть десять небольших сайтов местных компаний. На каждом несколько страниц, фотографии, контакты и форма обратной связи. Посещаемость небольшая, страницы хорошо кэшируются.
Такой набор способен совершенно спокойно работать на одном хорошем тарифе.
Теперь вместо них разместим десять интернет-магазинов. Каждый использует WooCommerce, фильтры товаров, поиск, корзину, личные кабинеты, импорт остатков и интеграцию с внешними сервисами.
Количество сайтов осталось тем же. Нагрузка изменилась радикально.
Именно поэтому вопрос «потянет ли тариф десять сайтов» без описания самих сайтов практически не имеет точного ответа.
Все проекты делят ресурсы одного аккаунта
В этом заключается главное отличие размещения нескольких сайтов на одном тарифе.
Они могут иметь отдельные домены, каталоги и базы данных, но вычислительные ресурсы хостинга обычно выделяются аккаунту в целом или ограничиваются правилами конкретной платформы.
Если один сайт внезапно начинает активно использовать процессор, это может повлиять на остальные.
Например, на одном WordPress запускается тяжелый импорт. В этот момент PHP обрабатывает большое количество данных, база получает множество запросов, создаются изображения и обновляются товары.
Другие сайты аккаунта ни в чем не виноваты, но часть общего ресурса уже занята.
Для небольших проектов это редко становится серьезной проблемой. Но чем больше сайтов собирается в одном месте, тем важнее понимать их суммарную нагрузку.
Процессор часто ограничивает раньше чем заканчивается место
Владелец нескольких сайтов может посмотреть на диск и увидеть прекрасную картину: из 30 ГБ занято только 7 ГБ.
Кажется, что можно добавить еще много проектов.
Но свободное дисковое пространство ничего не говорит о загрузке процессора.
Динамический сайт выполняет PHP-код, обращается к базе, запускает плагины и фоновые задачи. Чем больше одновременных запросов, тем больше вычислительной работы требуется серверу.
Поэтому аккаунт способен упереться в лимит CPU задолго до заполнения диска.
Особенно заметно это на нескольких WordPress с тяжелыми темами и большим количеством плагинов.
Если хостер предоставляет статистику нагрузки, при добавлении новых сайтов полезно периодически смотреть именно на нее, а не только на занятые гигабайты.
Количество PHP-процессов может стать скрытым ограничением
На динамических сайтах запросы часто обрабатываются PHP.
Если одновременно приходит много посетителей, серверу требуется обслуживать несколько запросов параллельно. Для этого используются рабочие процессы.
Когда доступный лимит занят, новые запросы могут ожидать освобождения ресурсов.
В результате владелец видит странную ситуацию: диска хватает, средняя посещаемость кажется небольшой, но в определенные моменты сайты начинают отвечать медленнее.
Особенно это заметно, если несколько проектов получают нагрузку одновременно.
Поэтому при сравнении тарифов для большого количества WordPress полезно смотреть не только на число разрешенных сайтов, но и на ограничения PHP и одновременных процессов.
Оперативная память тоже расходуется всеми сайтами
PHP, база данных и другие компоненты требуют RAM.
На виртуальном хостинге пользователь обычно не управляет памятью так же непосредственно, как на VPS, но ограничения все равно существуют.
Один тяжелый процесс может потреблять значительно больше памяти, чем обычный запрос небольшой страницы.
Если проектов много, вероятность одновременной активности возрастает.
Это еще одна причина, почему десять легких сайтов иногда чувствуют себя лучше одного сложного магазина.
Базы данных обычно не являются проблемой пока не появляется нагрузка
Большинство CMS используют базу данных. Если в аккаунте пять независимых WordPress, обычно будет и несколько отдельных баз.
Само их количество редко является главным ограничением.
Гораздо важнее размер, количество запросов и качество работы приложений с данными.
Небольшая база информационного сайта может создавать минимальную нагрузку. База магазина с фильтрами, заказами, поиском и большим количеством служебных данных работает совсем иначе.
Проблему способны создавать и плагины. Некоторые расширения записывают подробные логи, статистику или временные данные и постепенно раздувают таблицы.
Поэтому при размещении нескольких CMS полезно следить не только за количеством баз, но и за тем, что с ними происходит.
Кэширование сильно меняет реальное количество сайтов на тарифе
Хорошо настроенное кэширование позволяет обслуживать многие запросы без полного выполнения приложения.
Для информационного WordPress эффект может быть огромным.
Вместо того чтобы при каждом открытии страницы запускать PHP, обращаться к базе и заново формировать результат, сервер отдает уже подготовленную версию.
Поэтому несколько хорошо кэшируемых сайтов способны создавать меньшую нагрузку, чем один проект, который генерирует каждую страницу динамически.
Но кэширование не является волшебной кнопкой.
Корзина магазина, личные кабинеты, персонализированные данные и многие другие страницы требуют динамической обработки. Поэтому характер проекта все равно остается главным фактором.
Посещаемость важна но количество посетителей само по себе мало о чем говорит
Можно попытаться оценивать тариф по суммарному трафику всех сайтов.
Например, пять проектов получают по тысяче посетителей в день. Значит, аккаунт обслуживает пять тысяч посещений.
Но и здесь простой арифметики недостаточно.
Пять тысяч просмотров кэшированных статей и пять тысяч поисковых запросов по большому каталогу товаров создают разную нагрузку.
Кроме того, важен характер распределения посетителей.
Если трафик равномерный, серверу проще. Если большая часть аудитории приходит одновременно после рассылки или рекламной публикации, появляется пик.
Поэтому при размещении нескольких сайтов нужно смотреть не только на месячную или суточную посещаемость, но и на одновременную активность.
Один проблемный WordPress способен замедлить соседей
Это один из главных недостатков большого количества сайтов в одном аккаунте.
Предположим, девять проектов работают нормально. На десятом установили новый плагин, который начал выполнять тяжелые запросы или создавать множество фоновых задач.
Нагрузка всего аккаунта выросла.
В результате замедлиться могут сайты, на которых вообще ничего не менялось.
Похожий эффект дает ошибочный cron, генерация большого архива, импорт каталога или массовая обработка изображений.
Чем больше независимых проектов находится в одном аккаунте, тем выше вероятность, что один из них периодически будет создавать необычную нагрузку.
Резервное копирование нескольких сайтов тоже требует ресурсов
Бэкапы редко вспоминают при расчете количества сайтов, хотя они тоже создают нагрузку.
Нужно прочитать файлы, получить содержимое базы, иногда сжать данные и отправить их в хранилище.
Если на аккаунте находится десять сайтов и каждый ночью одновременно запускает собственный плагин резервного копирования, получается заметный пик.
Лучше распределить такие задачи по времени или использовать механизм резервного копирования самого хостинга, если он подходит по условиям.
То же касается других регулярных задач.
Импорт, очистка базы, генерация отчетов и обновления не обязательно должны стартовать у всех проектов в одну минуту.
Количество файлов тоже может иметь значение
Два сайта способны занимать одинаковый объем диска и при этом состоять из совершенно разного количества файлов.
Один хранит несколько крупных архивов. Другой содержит сотни тысяч мелких файлов кэша, миниатюр и временных данных.
Некоторые хостинги ограничивают количество файлов или inode в аккаунте.
Для обычного небольшого сайта этот лимит практически незаметен. Но при размещении большого количества CMS, кэшей, почты и резервных копий он способен стать реальным ограничением.
Если планируется много сайтов на одном тарифе, этот параметр стоит проверить заранее.
Почта тоже занимает место в аккаунте
Если хостинг используется одновременно для сайтов и корпоративной почты, дисковое пространство расходуют не только файлы CMS.
Несколько сотрудников могут годами хранить письма с вложениями. В результате почтовые ящики начинают занимать больше места, чем сами сайты.
При одном проекте это редко вызывает неожиданности. При десятке доменов с отдельной почтой ситуация меняется.
Поэтому для большого количества сайтов полезно уточнить, входит ли почта в общий дисковый лимит.
Есть ли смысл размещать все сайты в одном аккаунте
У такого подхода много преимуществ.
Один платеж, одна панель, одна учетная запись. Не нужно постоянно переключаться между хостерами и следить за сроками оплаты нескольких услуг.
Для группы небольших собственных проектов это действительно удобно.
Если сайты похожи по требованиям и ни один из них не является критичным для бизнеса, один хороший тариф может быть оптимальным решением.
Но удобство постепенно превращается в зависимость.
Чем больше проектов находится в одном аккаунте, тем серьезнее последствия любой проблемы с ним.
Безопасность является еще одной причиной разделять сайты
Несколько сайтов в одном аккаунте могут быть связаны не только общими ресурсами.
При определенной конфигурации проблема безопасности одного проекта способна создать риск для других.
Например, давно забытый WordPress не обновлялся несколько лет и содержит уязвимый плагин. Если злоумышленник получает возможность работать с файлами аккаунта, последствия могут выйти за пределы одного сайта.
Конкретный уровень изоляции зависит от архитектуры хостинга, поэтому нельзя утверждать, что любой взлом одного сайта автоматически означает взлом всех остальных.
Но общий принцип остается полезным: критичные проекты лучше не делать зависимыми от старых тестовых и малозначимых сайтов.
Сайты разных клиентов лучше разделять особенно внимательно
Для веб-мастера или небольшой студии идея разместить всех клиентов на одном большом тарифе кажется экономичной.
Технически это возможно.
Но нужно учитывать ответственность.
Один клиент запускает рекламу и создает всплеск нагрузки. Другой устанавливает проблемный плагин. Третий просит предоставить доступ к файлам. Все проекты находятся в одной инфраструктуре.
Чем больше независимых владельцев, тем сложнее управлять правами и рисками.
Поэтому для клиентских сайтов отдельные аккаунты, реселлерский хостинг или другая схема с нормальной изоляцией часто удобнее одного общего пользовательского тарифа.
Один большой тариф или несколько маленьких
Универсального победителя здесь нет.
Один большой тариф обычно проще администрировать. Он может оказаться дешевле нескольких отдельных услуг, а свободные ресурсы используются общей группой проектов.
Несколько аккаунтов дают лучшую организационную изоляцию.
Если один сайт создаст проблему с ресурсами, остальные меньше от нее зависят. Можно по-разному настраивать окружение, переносить отдельные проекты и предоставлять доступ разным людям.
Для пяти собственных небольших сайтов один аккаунт часто совершенно нормален.
Для пяти независимых коммерческих проектов разделение уже выглядит значительно интереснее.
Не стоит делить сайты только ради производительности
Иногда владелец видит замедление и сразу покупает второй хостинг, чтобы перенести туда половину проектов.
Это может помочь, если действительно закончились общие ресурсы.
Но сначала лучше найти причину.
Если всю нагрузку создает один плохо настроенный сайт, распределение остальных проектов ничего принципиально не исправит. Проблемный WordPress продолжит тормозить уже на новом аккаунте.
Сначала стоит посмотреть статистику CPU, процессов и других ресурсов, определить источник нагрузки и только потом решать, нужно ли разделение.
Когда одному тарифу становится тесно
Первый очевидный признак — сайты регулярно достигают ресурсных лимитов при нормальной рабочей нагрузке.
Не во время разового импорта или случайной ошибки, а в обычный день.
Второй признак — проекты начинают мешать друг другу. Нагрузка одного сайта заметно отражается на скорости остальных.
Третий — становится неудобно управлять безопасностью, доступами и резервными копиями.
Четвертый — один из сайтов стал значительно важнее остальных и требует более предсказуемой среды.
В такой ситуации можно перейти на более высокий тариф, вынести отдельные сайты в другие аккаунты или рассмотреть VPS.
Переход на VPS нужен далеко не из-за самого количества сайтов
Иногда кажется, что после пятого или десятого сайта автоматически пора покупать VPS.
Такого правила нет.
Десятки небольших сайтов могут нормально работать на подходящем виртуальном хостинге. А один сложный проект способен перерасти его гораздо раньше.
VPS становится интересным, когда нужны гарантированнее выделяемые ресурсы, собственные настройки сервера, нестандартное программное обеспечение или больший контроль над окружением.
Но вместе с ним появляется необходимость администрирования.
Поэтому переходить на VPS только ради красивой идеи «у меня много сайтов» необязательно.
Для сети небольших информационных сайтов виртуальный хостинг особенно удобен
Если проекты принадлежат одному владельцу, используют обычные CMS и имеют умеренную посещаемость, большой тариф виртуального хостинга может быть очень практичным.
Не нужно администрировать Linux. Провайдер занимается серверной инфраструктурой. Сайты создаются через одну панель, сертификаты подключаются автоматически, резервные копии уже встроены в услугу.
В этом сценарии возможность размещения большого количества сайтов действительно имеет ценность.
Главное, чтобы ресурсы тарифа соответствовали суммарной нагрузке.
Для важного интернет-магазина я бы не ориентировалась на свободные места тарифа
Представим, что тариф позволяет разместить десять сайтов, а сейчас занято только четыре.
Один из них превратился в активно работающий магазин.
Формально остается еще шесть свободных мест. Но это не означает, что стоит продолжать добавлять туда проекты.
Если магазин приносит деньги и получает заметную нагрузку, ему может быть полезнее отдельная среда с большим запасом ресурсов.
Так остальные сайты меньше влияют на магазин, а магазин — на них.
Количество свободных слотов здесь становится второстепенным.
Как приблизительно оценить сколько сайтов выдержит ваш тариф
Лучший способ — не пытаться вычислить число заранее, а использовать реальные показатели.
Разместите сайты, настройте их и посмотрите статистику потребления ресурсов в обычные дни.
Если аккаунт использует небольшую часть доступного CPU, не испытывает проблем с процессами, на диске достаточно места, а страницы открываются стабильно, запас есть.
Добавили новый проект — продолжайте наблюдать.
Так можно постепенно найти комфортную загрузку именно для вашего набора сайтов.
Это намного точнее универсальных обещаний «на тариф помещается двадцать WordPress».
Небольшой запас лучше работы постоянно у лимита
Использовать ресурсы тарифа на сто процентов круглосуточно не является хорошей целью.
Сайтам нужен запас для пиков.
Сегодня нагрузка обычная. Завтра одна статья получает много переходов из поиска, запускается реклама или начинается массовый импорт.
Если аккаунт уже работал на границе, небольшой всплеск становится проблемой.
Поэтому при размещении нескольких проектов разумно оставлять некоторый резерв, а не добавлять сайты до момента, когда хостинг физически перестанет позволять это делать.
Неиспользуемые сайты тоже лучше периодически удалять
Старый тестовый WordPress почти не потребляет CPU, если никто его не посещает. Поэтому кажется, что он никому не мешает.
Но он занимает место, попадает в резервные копии и требует обновлений.
Если про него забыть, устаревшие плагины и темы становятся ненужным риском безопасности.
Поэтому аккаунт полезно периодически очищать.
Если проект больше не нужен, сохраните необходимую копию и удалите его с рабочего хостинга.
Не стоит превращать тариф на двадцать сайтов в склад из двадцати старых установок WordPress только потому, что свободные слоты уже оплачены.
Что проверить перед покупкой хостинга для нескольких сайтов
Количество разрешенных сайтов все-таки важно, просто его недостаточно.
Перед покупкой полезно посмотреть на совокупность характеристик.
- Сколько отдельных сайтов разрешено разместить.
- Какие лимиты CPU действуют для аккаунта.
- Есть ли ограничения памяти и процессов.
- Сколько баз данных можно создать.
- Какой объем дискового пространства доступен.
- Есть ли ограничение количества файлов или inode.
- Как учитывается почта.
- Как создаются резервные копии.
- Можно ли посмотреть статистику потребления ресурсов.
- Насколько просто перейти на более высокий тариф.
Если часть характеристик не опубликована, их можно уточнить у поддержки до оплаты.
Так сколько же сайтов реально можно держать на одном хостинге
Столько, сколько одновременно помещается в ресурсные ограничения тарифа с нормальным запасом для пиков.
Для одного владельца это могут быть десять или двадцать небольших сайтов. Для другого один интернет-магазин уже использует значительную часть возможностей аккаунта.
Поэтому цифра в тарифе отвечает только на вопрос, сколько сайтов разрешает добавить провайдер.
На вопрос, сколько сайтов будут работать хорошо, отвечают их реальная нагрузка и доступные ресурсы.
Если речь идет о нескольких небольших визитках, блогах или информационных проектах одного владельца, размещать их вместе вполне нормально. Это удобно и часто экономически разумно.
Если один проект становится тяжелым, коммерчески важным или получает заметно больше посетителей, стоит подумать о его отделении.
А сайты разных клиентов полезно разделять не только из-за производительности, но и ради безопасности и удобного управления доступами.
Поэтому я бы не пыталась заполнить тариф до последнего разрешенного сайта. Лучше оставить запас, следить за фактической нагрузкой и добавлять новые проекты постепенно.
Если хостинг позволяет видеть потребление ресурсов и быстро менять тариф, точное количество сайтов вообще не нужно угадывать заранее. Вы начинаете с подходящей конфигурации и масштабируете ее тогда, когда реальные показатели покажут необходимость.
Именно это намного важнее рекламной надписи «до 50 сайтов». Иногда такой тариф действительно спокойно обслужит пятьдесят небольших проектов. А иногда один сложный сайт окажется для него более серьезной задачей, чем все остальные вместе.
