Мультисайтинг и хостинг

Главные вкладки

Аватар пользователя alexo alexo 4 июня 2018 в 19:46

Здравствуйте! Хочу поднять тему мультисайтинга и производительности в свете современных возможностей хостинга.
Есть ли существенная разница в типе хостинга (виртуальный, выделенные серверы, эластичный, облако или другие) с точки зрении производительности, на какие характеристики обращать внимание в случае планирования мультисайтинга временно на виртуальном хостинге (на первое время)? Какие варианты хостинга вообще лучше подходят?
Решает ли эластичный хостинг проблему производительности или нужно еще на что-то обращать внимание?
В какой ситуации нужно добавлять дополнительные базы данных? Можно ли как-то с помощью настроек хостинга увеличить допустимую нагрузку для одной БД?
Как правильно рассчитать, сколько сайтов можно добавить в мультисайтинг или какие нужно принимать меры в случае необходимости добавления большего числа сайтов?
Была вроде близкая тема но эта все же в другом свете.

Комментарии

Аватар пользователя bumble bumble 4 июня 2018 в 20:41
1

В целом, требования для хоста с мультисайтингом - такие же, как и для обычного сайта.
Помимо стандартных Drupal-реквайрментов - лучше выбирать именно UNIX-like сервера, т.к. нужны будут "нормальные" симлинки.

Базы, все же рекомендую юзать отдельные на каждый сайт. Меньше рисков потерять все сайты при возникновении поломки на каком-либо одном.

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

Аватар пользователя Semantics Semantics 4 июня 2018 в 21:46

Мультисайтинг для целей увеличения производительности вполне можно использовать, например, для "колхозного шардинга" с выносом отдельных разделов (форум, блоги, etc) на поддомены или для выноса специфичной бизнес-логики на отдельный админский поддомен.

Но для рядового сайта это наркомания и преждевременная оптимизация

Аватар пользователя alexo alexo 4 июня 2018 в 22:40

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

лучше выбирать именно UNIX-like сервера, т.к. нужны будут "нормальные" симлинки.

А что такое нормальные симлинки?

Аватар пользователя bumble bumble 4 июня 2018 в 22:51
1

alexo wrote:

понять как определить, что все предел, не тянет

Вы это сразу поймете, как только перестанет "тянуть" Wink

alexo wrote:

А что такое нормальные симлинки?

Это не ярлыки Windows, но работают за схожим принципом.

Аватар пользователя alexo alexo 4 июня 2018 в 23:26

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

Аватар пользователя bumble bumble 4 июня 2018 в 23:34

alexo wrote:

Как лучше, чтобы было я не пойму?

Чесн! Не знаю )))
Вам стоит найти больки-меньки актуальный тутор по изготовлению мультисайтинга на Drupal, и делать по аналогии.

Аватар пользователя alexo alexo 4 июня 2018 в 22:42

Semantics wrote:

например, для "колхозного шардинга" с выносом отдельных разделов (форум, блоги, etc) на поддомены

Спасибо, а что такое колхозный шардинг?

Аватар пользователя alexo alexo 28 июля 2018 в 16:05

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

Аватар пользователя DivaDii DivaDii 30 июля 2018 в 11:39
1

По поводу индексирования поисковиками.
Надо понимать так:
для поисковика сайт "по-тупому" состоит из домена и его содержания.

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

Все остальные внутренности (модули, настройки) поисковик вообще не видит, не воспринимает.
Ему на это вообще глубоко начхать.

Ну и всё.

Посмотрите на сайт РБК с кучей поддоменов (ТВ, Стиль, Спорт, Пинк...).

Аватар пользователя alexo alexo 14 февраля 2019 в 0:26

Еще раз думаю о мультисайтинге. Ситуация такая:
1.Есть разные тематики для разных пользователей, которые для удобства навигации пользователей необходимо вывести на разные домены (это позволит 1)убрать из меню два лишних уровня в глубину 2) не парится с тем, на каких страницах, какие меню, блоки вспомогательные отображать, ну и еще другие причины. Функционал сайтов при этом идентичный. Количество доменов с таким идентичным функционалом скорее всего не меньше десяти.

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

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

Если придется наверное мне все же делать мультисайтинг, то хочу предусмотреть на случай будущего переноса на отдельные совсем системы, как изначально лучше сделать?
1)базы будут отдельные,
2)остается вопрос по файлам и пути к файлам в случае переноса.
3)о чем-то еще нужно думать?

По второму пункту читаю (в т.ч. эту тему) у меня три варианта (частично это повтор и обобщение ранее сказанного):

1)Предположим базы данных у меня отдельные и я хочу перенести domain1.ru из мультисайтинга в отдельный.
Так как предполагаемая цель переноса - снижение нагрузки или упрощение навигации админов, то тогда предлагаю как вариант (?)
взять вспомогательные домен - муляж (настоящий или технический) как основной и с ним сделать мультисайтинг из моего целевого сайта, который надо перенести.
Т.е. выделить целевой сайт фактически из рабочего мультисайтинга на мультисайтинг чисто архитектурый, который содержательно по наполнению на самом деле будет моносайтом
Ну т.е. лежал целевой сайт у меня предположим в папке
hosting_account_name/main_default_site/sites/domain1
А рядом с ним еще были
hosting_account_name/main_default_site/sites/domain2

hosting_account_name/main_default_site/sites/domain3

а теперь будет в папке

hosting_account_name/tech_domain_site/sites/domain1
И никаких других сайтов рядом с ним не будет
(это должно решить же и проблему с нагрузкой и с навигацией админов?)

Какие могу быть проблемы с таким вариантом?

Два других варианта с большим сложностями могут быть по осуществлению:

2) второй вариант запасной, при переносе создать папку уже на отдельном домене
sites/domen1/files и все имеющиеся файлы перенести в нее, ну и как-то проверить, чтобы путь прописывался, как надо

3)изначально при создании мультисайтинга файлы расположить не внутри папки домена, а папке default:
для этого в папке default/files сделать папки для файлов для каждого из сайтов и это путь например
default/files/domen1
Я только пока не пойму как при коробочном мультисайтинге путь выше корня сайта прописывается для дополнительных сайтов?
Придется править руками где-то в базе? а где?

или где-то в настройках модулей добавлять возможность прописать через админку ( admin/config/media/file-system) не от корня сайта, а от корня аккаунта?

Это гипотетически, не знаю на практике, как получится через админку путь прописать (там наверное все же от корня сайта путь идет, т.е. придется куда-то чуть ли не в ядро лезть, чтобы иметь возможность путь не от корня сайта прописать)

Аватар пользователя alexo alexo 14 февраля 2019 в 0:38

т.е. придется куда-то чуть ли не в ядро лезть,

и наверное в ядро лучше не лезть тем более из-за такого, и если другого пути нет, то остается первый вариант?

Аватар пользователя alexo alexo 5 апреля 2019 в 14:03

Обновление:
При создании сайтов с разными базами данных выяснилось что все настройки тогда не переносятся (чего и следовало ожидать).
Кто-то может поделиться конкретными цифрами сколько сайтов с каким общим трафиком у вас нормально работает на одной базе?
Что Вы думаете о решении проблемы, какой способ лучше:
1)все же делать общую базу?
2)делать разные базы и часть настроек переносит с помощью features?
3)переходить на Друпал 8, чтобы нормально переносить конфигурацию
4)делать разные базы с общими таблицами?
Кстати такие цифры встретились по общим базам и таблицам на хабре в комментахх:
"У меня вполне отлично 20 сайтов в одной БД (около 250 таблиц) — суммарный трафик не большой, но проблем вообще никаких пока. ...
Опытным путем определил для себя таблицы, которые можно делать общими (Drupal 6):

default, access, actions, actions_aid, authmap, imagecache_action, imagecache_preset, filter_formats, languages, locales_source, locales_target, l10n_update_file, l10n_update_project, permission, role, sessions, term_data, term_hierarchy, term_relation, term_synonym, users, users_roles, vocabulary, watchdog, wysiwyg, wysiwyg_user."

Аватар пользователя DivaDii DivaDii 5 апреля 2019 в 14:16
1

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

У меня сейчас есть проект на 7ке.
"Пучок" 6 доменов. Плюс, скорее всего, будет ещё минимум один. Или парочка.
Сделано с помощью модуля Domain Access.
Но с самого начала делала с этим модулем. Потому что понимала, какой дальше будет "пучок" сайтиков.
Посещалка сейчас ещё маленькая - до 100 человек в день. Проект совсем новый.
База небольшая. С обновлением никаких проблем нет.

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

А для других вариантов - надо решать каждый раз заново.

Хочу ещё сделать минимум 2 "связки" своих проектов.
Только всё времени не хватает.
И жалею, что некоторые проекты с самого начала так не делала. Потому что не знала, что такое возможно, и что это достаточно просто.

Аватар пользователя alexo alexo 5 апреля 2019 в 14:22

Спасибо. А как Вы настроили на domain access, чтобы разделить материалы на разные домены. У меня просто в ноде даже при выбранном нужном сайте из связки все равно публикуется на всех сайтах одно и то же. Никак не могу ограничить. Какая у Вас версия Друпал 7 и domain access?

Также какой способ Вы выбрали для подтверждения прав для поисковиков?

Аватар пользователя alexo alexo 5 апреля 2019 в 14:29

еще добавляю тогда пятый вариант с учетом этого, но исходя из моей проблемы с domain access придется добавлять танцы с бубном
5)Делать на domain access, но как-то решать проблему с ограничением видимости только на нужном домене,
например, делать для каждого домена свой тип материала

Аватар пользователя adano adano 5 апреля 2019 в 15:06
1

Вы опасаетесь чрезмерной нагрузки на БД? Забудьте, времена уже давно не те.

Что Вы думаете о решении проблемы

В чем конкретно проблема?

А так, 4 пункт наиболее приемлемый, если нужно что-то расшарить. Иногда DA - профитней. От кейса отталкиваться нужно.

Аватар пользователя alexo alexo 5 апреля 2019 в 15:44

adano wrote:
Вы опасаетесь чрезмерной нагрузки на БД? Забудьте, времена уже давно не те.

Да. Хотелось бы по практическому опыту услышать хоть какие-то конкретные цифры . Ну например что трафик в градациях 100 -1000-10000 в день тянется нормально и т.д. Пока есть цифра 100 в стуки на 6 доменах.
И вообще интересно, что больше влияет на то потянет ли база данных, количество доменов или трафик?

Аватар пользователя adano adano 5 апреля 2019 в 16:16
2

Давайте от "обратного":

Я сильно сомневаюсь, что вы сейчас найдете такие проблемы "БД перегружена, сайт крашится/сервак не справляется".
Не спорю, могут быть сайты на вордпресс, которые загоняют проц в 100%. Либо проекты, жрущие оперативку хлеще винды10 с хромом (100+ вкладок)... Но это уже совсем другие истории.

Если что-то и услышите, то не факт что это будет применимо именно к вам.

По своему опыту: свои серваки, все летает. Если вдруг станет не хватать какой-то железки (ssd, оперативки)
- куплю, они копейки стоят.

+ сейчас инструментов для кеширования - вагон и маленькая тележка.

И вообще интересно, что больше влияет на то потянет ли база данных, количество доменов или трафик?

Запросы.

Аватар пользователя adano adano 5 апреля 2019 в 16:32
1

Ну и самое главное по сабжу:

Если проект становится удачным, имеет шикарный траффик. Он автоматом отцепляется от мультисайтинга. Живет своей инфраструктурой, поддержкой, обслуживанием, финансами и т.д. Это аксиома.

Аватар пользователя vlucas vlucas 7 апреля 2019 в 11:49
1

Всё правильно писали выше: подходы, способы реализации, всё это сугобо от задачи зависит.

Вот например D8, и если у вас есть кластер сайтов с одинаковой структурой, типами, вьюсами, и т.д. и велика вероятность того что это со временем не измениться(не сильно измениться) но разным содержимым, то я бы использовал мультисайтинг с разными базами, но частично одинаковыми конфигами. В таком случае, если вам нужно добавить новый тип материала, например, на одном сайте, то можно организовать деплой, чтобы это всё применялось и для всех остальных.

Применение domain access тоже зависит от задачи. Он не плох, где требуется сэкономитьт время. Но бывает несовсем гибок.

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

Аватар пользователя alexo alexo 8 апреля 2019 в 14:38

Спасибо. Я еще раз продумываю все возможные способы.
Пока вопрос еще такой: в чем отличие между тем, чтобы переносить с фичами и дистрибутивом?
Стоит ли осваивать дистрибутив? Как быстрее всего делать свой дистрибутив, использовать модули для этого?
Дистрибутив и настройки конфигурации и правки файлов тоже переносит (например я в файле шаблона нод стираю для заголовка слово Welcome, мне приходится на каждом сайте заходить в этот файл и править, либо патчем это править). Дистрибутивом это же можно будет тоже переносить?
Все способы пока выглядят так:
1)дистрибутивы
2)копипаста drush si, drush en, cp
(но все равно потребуется редактировать некоторые файлы)
3)копирование с редактированием
4)мультисайтинг
а)коробочный
б)domain (предпочтителен, когда может быть одна бд, но сложности с разделением потом и с разделением контента по сайтам)
5)фичи
6)конфигурация Друпал 8

Аватар пользователя vlucas vlucas 8 апреля 2019 в 14:42
1

На мой взгляд, это разные вещи.
Если про D8 то здесь фичи практически не нужны. Если вы имеете конфигурацию сайта - вот вам и дистрибутив. Мультисайтинг - это из другой оперы.
Может я не совсем всё понял, то что требуется.

Аватар пользователя alexo alexo 8 апреля 2019 в 14:51

Спасибо. Все эти пунткы перечисляют способы быстрого создания однотипных сайтов. Мультисайтинг здесь просто как один из способов. Функционал типа общих паролей и т.д. в моем случае пока не главное.
В 6 пункте имеется ввиду переход с Друпал 7 на Друпал 8, если все остальное не решило проблему

Аватар пользователя vlucas vlucas 8 апреля 2019 в 14:51
1

На 8 в любом случае придётся, т.к. поддержка не вечная и чем раньше - тем лучше. Как раз и про фичи забудете.

Аватар пользователя alexo alexo 8 апреля 2019 в 15:53

Тестирую сейчас domain и features.
Минус domain для меня в том, что ноды публикуются на всех сайтах при проставленых галках для публикации только на выбранных (у кого-то работаете нормально сейчас новая версия модуля domain?).
Фичи многое, как выяснилось, все же не переносят.
На Друпал 8 мне пока рано, так как не все нужные мне модули на нем есть.
Остается мультисайтинг.
С ним сложность в том, что при установке нового сайта с той же таблицей затираются данные для старого.
Тогда вариант делать по этой инструкции с частью общих таблиц прописанных в сеттингс.
На хостинге мне рекомендуют сначала ставить с разными базами, чтобы не затирать старую базу при инсталляции, а потом править сеттингс.
Я предполагаю сделать все таблицы общими, кроме контента и тем оформления:
I) если сайты будут использовать одну и ту же БД
1)В sites/first.ru/settings.php пишем:

// $db_prefix = '';

$db_prefix = array(
"default" => "default_",
(т.е. все таблицы будут общими)
дальше в нем нужно прописать только отдельные таблицы для контента и тем оформления
Как?

2)В sites/default/settings.php

// $db_prefix = '';

$db_prefix = array(
"default" => "default_",

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

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

Чтобы как-то разделить контент по сайтам я предполагаю сделать отдельные таблицы для контента

А опять же, какие таблицы отвечают за контент?

Аватар пользователя vlucas vlucas 8 апреля 2019 в 15:54
1

Помоему вам проще будет разобраться с D8 чем разбираться с тем с чем вы сейчас разбираетесь. А какие модули под 8 вам нужны?

Аватар пользователя alexo alexo 8 апреля 2019 в 16:17

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

Аватар пользователя alexo alexo 11 апреля 2019 в 12:16

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

Аватар пользователя adano adano 11 апреля 2019 в 12:27

Вообще, если честно, после этого даже у меня уже идея мультисайтинга начинает вызывать сомнения.

А я вообще не понял, для чего вам мультисайтинг.

Кстати, это распространенная проблема. Каждый по своему трактует "мультисайтинг". Отсюда: и разбитые ожидания, и непонятные решения.

Аватар пользователя alexo alexo 11 апреля 2019 в 13:14

А я вообще не понял, для чего вам мультисайтинг.

Чтобы быстро делать однотипные сайты на Друпал 7.

Аватар пользователя vlucas vlucas 11 апреля 2019 в 13:15
1

Если в приоритете "быстро", то это не про D7.
С D8 и его деплоем гораздо быстрее и гибче делать однотипные.

Аватар пользователя adubovskoy adubovskoy 11 апреля 2019 в 13:16
1

alexo wrote:

А я вообще не понял, для чего вам мультисайтинг.

Чтобы быстро делать однотипные сайты на Друпал 7.

у вас будет много боли и разочарований на этом пути) для задачи "делать однотипные сайты" d8 на порядок комфортнее.

Аватар пользователя alexo alexo 12 апреля 2019 в 11:50

Спасибо большое всем за ответы. Ну тогда два уже сделанных на мультисайтинге сайта оставлю пока так, и для других подумаю, что делать с самописами, потому что следующие сайты все же попробую на Друпал 8. Не могу никак себя заставить освоить composer по-нормально, мне привычно все же пока просто по SSH и с drush.
Тогда какой источник "попроще" порекомендуете именно по быстрому перенесу конфигурации? Все остальное буду делать с drush и SSH.

Еще вылез глюк с фавиконами. Они загружаются, но потом через пару дней исчезают и из браузера и в вебмастере сообщение что Яндекс их не видит. Файл был в этот раз правдае не .png, a .ico. Как у Вас работает ico?
Как Вы думаете это из-за другого пути к файлу или из-за формата? Здесь читаю, но не понятно, почему не сразу глючит, а спустя сутки?
неужелит придется
html.tpl.php в районе <?php print $head; ?> выводить иконку в правильном формате
или ставить модуль https://drupal.org/project/favicon