"gorr" wrote:

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

Под управлением я имел ввиду именно редактирование содержимого (новости, объявление и т.п.)

В качестве примера
tiu.ru - главный сайт
novosibirsk-instar.tiu.ru - поддомен.
Посещаемость проекта 70.000 хостов.

Как можно посчитать ресурсы?

"xxandeadxx" wrote:

насколько хорош ваш сервер?

На данный момент это виртуальный сервер 500 Мб оперативки, дальше уже будет выделенный в зависимости от нагрузки. Но ведь самый мощный сервер можно увалить одним запросом.

"Sinkora" wrote:

По-моему, все зависит от того, что подразумевать под Друпалом. Если бездумно использовать Друпал как цмс, конструктор, со всеми модулями типа locale, pathauto, views, cck и т.д., то никакой хостинг вам не поможет при больших нагрузках. А если рассматривать Друпал как фреймворк, писать под него свои модули, применять стратегии кеширования, понимать как работает система, то все должно быть гуд. Сам Друпал в чистом виде совсем не тяжелый.

Так говорит мой опыт. Если я не прав, значит я еще чего-то не понимаю в этой жизни:)

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

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

Также очень интересно как по мне система djem.ru - эта cms генерит статику. Только вот программистов на ней мало.
Еще нашел недавно систему jcore.net

"Crea" wrote:

Лучше делать в виде "каждому сайту -своя база". На одной базе оно "не взлетит" (большое количество JOIN все портят).
Грубо говоря, если решитесь, вам придется написать свою обвязку, наподобие Aegir

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

"Sinkora" wrote:

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

Если можно чуть подробнее. Интересует готовые решения с генерацией html страниц.

"Dan" wrote:

Очередные одноклассники? Можно узнать, откуда такие цифры?

"xxandeadxx" wrote:

http://drupal.org/project/boost тут даже php подниматься не будет :)

Но есть 2 серьезных недостатка:

Кеш не работает для авторизованных пользователей.

Кеш не обновляется при изменениях на сайте, а только после истечения время жизни.

"Dan" wrote:

Что значит фраза "мог им управлять как отдельным сайтом"? Какой конкретно нужен функционал? Иногда не обязательно делать мультисайтийнг, достаточно сделать видимость :)

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

"Dan" wrote:

Из коробки. У каждой ноды - свой автор, вам надо будет только настроить вывод всех новостей, товаров и т,д. в профиле пользователя.

Спасибо.

Я пока еще в раздумьях как наиболее оптимально построить эту систему.

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

Пользователь может наполнять свой минисайт содержимым. Сами пользователи друг с другом никак не взаимодействуют.

Еще одна важная функция - авторизация. Если пользователь авторизовался на главном сайте, он автоматически авторизуется и на своем минисайте.

"Dan" wrote:

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

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

Я подумал о мультисайтинге после прочтения статьи о внедрении drupal на сайт In-Fisherman.com
http://drupal.org/node/497008
там в 5 пункте явно пишут о разных базах.

Quote:

Sharing Data across multiple domains - The In-Fisherman.com site uses several databases to support high-volume traffic. The technique used relied heavily on Drupal’s multi-site configuration. Drupal points to a particular database, based on the subdomain of the URL. This posed a problem for blocks that presented data across multiple subdomains. IMO didn’t want to make database calls from one subdomain to another. To solve this, Mediacurrent created a set of modules that would “flatten” a block’s content to a serialized array and store it in a flat file. Thus, block content on one subdomain could be read by another subdomain without a database request. Another challenge of multiple domains is making Drupal’s menu system point to the correct domain when routing a page request, without having to use absolute URL’s. Mediacurrent created the Multidomain module to pass navigation and /user paths through a custom_url_rewrite_outbound() function. A switch statement in the function assigns the correct domain for a given path. Without this module, absolute URL paths would have to be written everywhere to accommodate multiple domains.

"Sinkora" wrote:

о_О Для меня это новость!!!

А что вас смущает? Время отклика сайта и скорость отдачи контента - один из 200 факторов ранжирования Google. Об этом неоднократно писал Мэт Катс, программист Google.

И по моим наблюдениям этот фактор играет далеко не последнюю роль.

И ЧПУ хорош не только тем, что контент лежит по адресу username.tiu.ru/shop/nokia/nokia_8800.html и отдается мгновенно, а еще в возможности просматривать содержимое по любому адресу username.tiu.ru/shop/nokia/, с Псевдо-Чпу с этим часто проблемы.

Посмотрите, например, генераторы доров, почему они генерируют *.html статику? Гораздо проще было бы залить контент в базу php-движка и не мучаться. Вопрос на самом деле достаточно серьезный.

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

"Sinkora" wrote:

Для этого в Друпале существует API кеширования.

"Dan" wrote:

В друпале нет никаких папок типа "shop/nokia_8800.html", все пути виртуальны, кроме путей к бинарным файлам (да и они не всегда реальны). Если есть желание, можете сайт на друпале в статику кэшировать, есть модули.

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

Есть у меня один крупный сайт на joomla, так вот там напротятежении года периодически слетали теги title c "Название статьи-Название сайта"
на "Название сайта" и это было замечено только недавно. Представляете, какой это ущерб наносило сайту? Сбоила система кеширования.

"Sinkora" wrote:

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

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

"Sinkora" wrote:

Вы ничего не понимаете в веб-разработках.

Я об этом честно сказал, я продвигальщик сайтов и потому так много про статику говорил.
И не конкретно друпал, а вообще Псевдо-ЧПУ считаю злом.
Вот один из примеров недо пседо-ЧПУ, которое можно встретить сплошь и рядом:
http://www.discogs.com/The-Beatles-Let-It-Be/release/1193791

По-поводу самого движка. Я неоднократно размещал заказы на free-lance.ru, там были предложения писать сайт на основе wordpress, symphony, drupal, modx, joomla, djem и т.д. Но меня как заказчика интересует также расширяемость этого движка в будущем, возможность поддержки кода другим программистом и т.д. Ведь каждый из них имеет свою область применения и возможности, поэтому я и пришел сюда.

В любом случае, спасибо за терпение и поддержку.