На различных форумах много пишут о том, что друпал очень тяжел, поэтому мне бы хотелось услышать мнение об этом движке непосредственно от людей, которые пишут на нем сайты.
Передо мной стоит задача сделать мультисайтовость, чтобы при регистрации пользователь получал поддомен и мог им управлять как отдельным сайтом: user.site.ru. Таких поддоменов может быть достаточно много 50-100 тысяч и все они должны быть логически связаны по категориям на главной странице основного сайта.
Подойдет ли для этой задачи друпал? Если нет, то какой движом наиболее близок к этой задачи.
Комментарии
более чем подойдет.
насколько хорош ваш сервер?
Впринципе можно, но тут непонятно, что подразумевается под "мог управлять им" - если полный доступ, как у админа, с возможностью ставить модули и т.д., то это совсем не безопасно, если же имеются ввиду весьма ограниченные возможности, например по наполнению и структурированию контента, то все можно. По нагрузке - 100тыс непосещаемых и редко обновляемых сайтов, с малым кол-вом пользователей или наоборот куча больших посещаемых ресурсов, на каждом из которых идет активная деятельность и общение - две разные вещи. Вообще не сильно будет отличаться нагрузка от 100тыс. отдельных сайтов. Посчитайте просто кол-во ресурсов, которое необходимо для такого кол-ва сайтов.
Лучше делать в виде "каждому сайту -своя база". На одной базе оно "не взлетит" (большое количество JOIN все портят).
Грубо говоря, если решитесь, вам придется написать свою обвязку, наподобие Aegir
По-моему, все зависит от того, что подразумевать под Друпалом. Если бездумно использовать Друпал как цмс, конструктор, со всеми модулями типа locale, pathauto, views, cck и т.д., то никакой хостинг вам не поможет при больших нагрузках. А если рассматривать Друпал как фреймворк, писать под него свои модули, применять стратегии кеширования, понимать как работает система, то все должно быть гуд. Сам Друпал в чистом виде совсем не тяжелый.
Так говорит мой опыт. Если я не прав, значит я еще чего-то не понимаю в этой жизни:)
Под управлением я имел ввиду именно редактирование содержимого (новости, объявление и т.п.)
В качестве примера
tiu.ru - главный сайт
novosibirsk-instar.tiu.ru - поддомен.
Посещаемость проекта 70.000 хостов.
Как можно посчитать ресурсы?
На данный момент это виртуальный сервер 500 Мб оперативки, дальше уже будет выделенный в зависимости от нагрузки. Но ведь самый мощный сервер можно увалить одним запросом.
Ну вот например, когда я отправляю ответ в этот форум, то после нажатия кнопки "Сохранить" проходит 5-10 секунд. Это ж может означать то, что движок сам по себе прожорливый.
P.S. Мне очень нравится друпал и если бы была уверенность, что он выдержит большие нагрузки, остановил на нем свой выбор. Разумеется я понимаю, что все зависит от архитектуры и оптимизации, но и сам движок может быть очень грузным.
Был бы признателен, если бы вы привели примеры нагруженных сайтов на друпал.
Также очень интересно как по мне система djem.ru - эта cms генерит статику. Только вот программистов на ней мало.
Еще нашел недавно систему jcore.net
Но ведь мне все равно придется выводить на главный сайт информацию из этой тучи отдельных баз.
К тому же, как поведет себя Mysql при большом количестве отдельных баз не представляю.
Это и есть обвязка, упомянутая мной
Уж лучше чем с 1 базой на миллионы записей.
Добавочный бонус: горизонтальное масштабирование из коробки.
Не судите только по этому сайту. Конечно, 5-10 секунд - это очень много. Нормально - 1-2 секунды. Здесь стандартный механизм комментирования, его можно оптимизировать, аякс в помощь:) И все будет гуд:)
Ссылки на популярные сайты на Друпале найдете сами в интернете.
Думаю, все-таки друпал не справиться с этой задачей. Оптимизируй, не оптимизируй, все равно упрешься в ресурсы сервера.
Я в последнее время все больше присматриваюсь к djem как системе идеально подходящей для высоконагруженных проектов - там ведь php используется единожды для генерации html страниц, а весь контент статичен и лежит реально в каталогах на сервере.
infox.ru - 300.000 хостов, газета.ру, мгимо.ру, експерт.ру все на этой системе работает.
По-началу думал, что она только для статичных сайтов подойдет, где содержимое нечасто меняется, но когда увидел
velorama.ru - социальная сеть на ней, понял что ошибался.
Но, к сожалению, система стоит очень дорого и на ней пишут не так много программистов.
Такое можно делать и на Друпале.
Еще и платить за чужой велосипед:)
Уж лучше бесплатные популярные php-фреймворки использовать, или своими силами движок разрабатывать, чем платить за технологию, бесплатных альтернатив которой полным полно.
Если можно чуть подробнее. Интересует готовые решения с генерацией html страниц.
http://drupal.org/project/boost тут даже php подниматься не будет
Zend Framework, CakePHP, Code Igniter, Kohana, Symfony...
Введите в гугле что-то типа "php-фреймворки".
Хм, так все движки сайтов генерируют html:)
Очередные одноклассники? Можно узнать, откуда такие цифры?
По теме: http://sf2010.drupal.org/conference/sessions/24-million-page-views-day-6...
tiu.ru
Спасибо, очень интересный модуль.
Но есть 2 серьезных недостатка:
Кеш не работает для авторизованных пользователей.
Кеш не обновляется при изменениях на сайте, а только после истечения время жизни.
Для этого в Друпале существует API кеширования.
Что значит фраза "мог им управлять как отдельным сайтом"? Какой конкретно нужен функционал? Иногда не обязательно делать мультисайтийнг, достаточно сделать видимость
Dan, ты имеешь в виду только использование мод_реврайта?
Идея такова: дать пользователю на поддомене сайт-визитку, чтобы он мог создавать категории, пункты в меню, добавлять товары, новости, изображения, и при этом, чтобы все происходило на уровне визуального редактора кода.
Да. Или подобных вариантов, типа [module=purl]
Это можно сделать, ограничив действия пользователей некой зоной. Вижу несколько путей:
- создание зон сайта: OG, [module=spaces]
- разграничение прав: TAC lite, content access
- свой модуль
Из коробки. У каждой ноды - свой автор, вам надо будет только настроить вывод всех новостей, товаров и т,д. в профиле пользователя.
Спасибо.
Я пока еще в раздумьях как наиболее оптимально построить эту систему.
У меня единица системы минисайт на поддомене, он содержит уникальные новости, товары, форму контактов, а главный сайт связывает минисайты в общий каталог товаров.
Пользователь может наполнять свой минисайт содержимым. Сами пользователи друг с другом никак не взаимодействуют.
Еще одна важная функция - авторизация. Если пользователь авторизовался на главном сайте, он автоматически авторизуется и на своем минисайте.
Не заморачивайтесь с этой мультисайтовостью. Тут и без неё обойтись можно. Сначала всё разделите, потом будете в кучу сгребать для того чтобы показывать последние новости, тэги или ещё что-то в роде.
Я тоже такое хочу сделать на своем сайте www.ukr-firma.com Только мне кто-то сказал что на друпал такое не сделать. А тут почитал и многие говорят что возможно сделать.
К примеру личная страница предприятия сейчас выглядит так http://ukr-firma.com/company/89 а я хочу чтоб было так http://ukr-firma.com/company/89 и так energo.ukr-firma.com Ну и так сделать для всех пользователей. А сделать это хочу так:
1) В админке пользователя будет поле куда он введет слово, к примеру test нажмет кнопку сохранить или что-то в этом роде и автоматически получит такую ссылку test.ukr-firma.com на свою страничку.
Такое реально сделать????????????
Ukrfirma, реально
А примерно по цене кто-то может с ориентировать?
Я вас правильно понял, что можно обойтись без создания копий баз данных, а все сделать в рамках одной базы? Только не представляю как сделать минисайт на поддомене полностью независимым: отдельный поддомен, без ссылок на главный сайт и собственную авторизацию.
Я подумал о мультисайтинге после прочтения статьи о внедрении drupal на сайт In-Fisherman.com
http://drupal.org/node/497008
там в 5 пункте явно пишут о разных базах.
- "отдельный поддомен". Создаём страницу профиля для пользователя, например tiu.ru/profile/username, запрещаем доступ к стандартным профилям, делаем переадресацию (mod_rewrite апача или custom_url_rewrite_outbound друпала) на username.tiu.ru.
- "без ссылок на главный сайт". Это в ваших руках полностью - какие ссылки на страницу поместите, такие и будут.
- "собственную авторизацию". А вот тут подробнее. На поддомене будет один пользователь или много? Если один, то всё просто - при логине перебрасываем пользователя в профиль. Если много, то... зачем? Зачем нужны пользователи? Админить мини сайт, отвечать на комменты или ещё что-то?
Т.е. я правильно понимаю, что username.tiu.ru можно сделать полностью автономным с использованием mod_rewrite апача или custom_url_rewrite_outbound и построить такую структуру:
username.tiu.ru/news - раздел новостей
username.tiu.ru/shop - страница товаров
username.tiu.ru/shop/nokia_8800.html - страница конкретного товара
Но ведь каждая такая переадресация сильно нагрузит apache ?
Я больше не программист, а сео-оптимизатор, так вот когда один из сайтов мы перевели на движок, который полностью генерирует сайт в статику *.html, траффик с поисковиков вырос в 1.5 раза. С 8500 до 11500 хостов. Есть еще ряд примеров, но они менее наглядны.
Т.е., убеджен, что псевдо-ЧПУ с помощь mod_rewrite и задержка на php-генерацию на лету - отрицательно сказывается на
индексацию и ранжирование в поисковых системах.
Ну и конечно, если сайт статичен - это в разы снимает нагрузку.
Поэтому возможно ли сделать чтобы страницы username.tiu.ru/shop/nokia_8800.html реально лежали в в папке shop с именем nokia_8800.html ? Я могу ошибаться, но вроде бы modx умеет такое делать. А вот в drupal как такое реализовать?
Насчет авторизации - только один пользователь может управлять минисайтом. Множества пользователей там не будет.
Апач или php, смотря как делать будете. Не нагрузит, это реализуется простым регулярным выражением.
В друпале нет никаких папок типа "shop/nokia_8800.html", все пути виртуальны, кроме путей к бинарным файлам (да и они не всегда реальны). Если есть желание, можете сайт на друпале в статику кэшировать, есть модули.
Я не первый раз слышу подобные выводы, как правило выясняется, что делали не только конвертацию, но и ещё что-то, поэтому нельзя говорить о чистоте эксперимента.
о_О Для меня это новость!!!
А что вас смущает? Время отклика сайта и скорость отдачи контента - один из 200 факторов ранжирования Google. Об этом неоднократно писал Мэт Катс, программист Google.
И по моим наблюдениям этот фактор играет далеко не последнюю роль.
И ЧПУ хорош не только тем, что контент лежит по адресу username.tiu.ru/shop/nokia/nokia_8800.html и отдается мгновенно, а еще в возможности просматривать содержимое по любому адресу username.tiu.ru/shop/nokia/, с Псевдо-Чпу с этим часто проблемы.
Посмотрите, например, генераторы доров, почему они генерируют *.html статику? Гораздо проще было бы залить контент в базу php-движка и не мучаться. Вопрос на самом деле достаточно серьезный.
Обидно, что в drupal нет генерации реальной статики. Опять же плюс в сторону коммерческой системы djem. В контексте нагруженных проектов разумеется.
К сожалению, кеширование через различные модули drupal и API - все это вместе часто конфликтует, сюрпризы могут вылезти на каждом шагу. Взять хотябы кеширование для залогиненных и кеширование для неавторизованных пользователей.
Есть у меня один крупный сайт на joomla, так вот там напротятежении года периодически слетали теги title c "Название статьи-Название сайта"
на "Название сайта" и это было замечено только недавно. Представляете, какой это ущерб наносило сайту? Сбоила система кеширования.
dmisoh, мы с вами тут вообще на разных языках общаемся.
Вы все время пытаетесь доказать, что Друпал - это глючная, тормознутая система, которая ничего не умеет. Но это неправильный взгляд на вещи. Чтобы делать такие выводы - изучите код системы и найдите в нем хоть один баг - тогда я буду вас слушать.
Я же хотел сказать, что Друпал тут не самое главное. Главное - это вообще понимание всего процесса создания сайта. И все зависит только от разработчиков в первую очередь. И не нужно 100 раз говорить про статику. Вы ничего не понимаете в веб-разработках, и все что говорит Dan и другие люди, пропускаете мимо ушей...
Нисколько, наоборот я пока другой альтернативы ему не вижу. Просто пытаюсь понять, какие могут возникнуть проблемы и понять насколько он мне подходит.
Я об этом честно сказал, я продвигальщик сайтов и потому так много про статику говорил.
И не конкретно друпал, а вообще Псевдо-ЧПУ считаю злом.
Вот один из примеров недо пседо-ЧПУ, которое можно встретить сплошь и рядом:
http://www.discogs.com/The-Beatles-Let-It-Be/release/1193791
По-поводу самого движка. Я неоднократно размещал заказы на free-lance.ru, там были предложения писать сайт на основе wordpress, symphony, drupal, modx, joomla, djem и т.д. Но меня как заказчика интересует также расширяемость этого движка в будущем, возможность поддержки кода другим программистом и т.д. Ведь каждый из них имеет свою область применения и возможности, поэтому я и пришел сюда.
В любом случае, спасибо за терпение и поддержку.
Я думал здесь технические специалисты собрались, а здесь обсуждают слухи, мистику, и прочее шаманство. Тьфу.
А что вы хотели здесь услышать?
Интересна интегральная оценка влияния скорости загрузки на ранжирование, а не процентная. То есть важен вес скорости в общей оценке ранжирования. Каков он? Есть подобная информация?
ЧПУ в друпале можно сделать разными способами, соответственно и влияние на загрузку будет различным.
Это проблема не движка, а прямых рук программиста и архитектуры сайта в целом. Drupal не будет думать за программиста.
Поисковики - это гости, для гостей в друпале с кэшированием всё отлично. И файловый кэш тоже есть - включайте и поисковики будут выкачивать статику.
Это не к нам
Расширяемость и модульность - это одна из сильных сторон друпала, пожалуй равных ему в этом нет.
По-моему в друпале псевдо-ЧПУ неплохо работает и руки кривые ничего не испортят)))
а приведенный в топике infox.ru
разве не на друпале?