Iced Drupal

там птичка в друпале есть "кеширование" - ее нажать надо. в sql хранить более правильно так как она масштабироватся умеет

Надо пробовать. У меня есть проект небольшого сайта, где не требуется частое обновление контента. Если клиент созреет, попробую обязательно.

Это разные задачи. Понятно, что с кешированием быстрее (выключать его вообще не рекомендуется в друпале) - количество запросов снижается на порядки (для анонимных пользователей). Но есть задачи где хранение в БД вообще нафиг не сдалось. Но нужна категоризация контента и т.п. Тут же можно делать "статико-динамический" сайт - часть контента генерится в динамике (форум, комментарии), а доки к примеру - лежат файлами на диске.

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

--
Axel,
www.axel.drupal.ru

Модуль не качается. Ошибка. 502 Bad Gateway.

Это ошибка хостинга - нагрузка большая была в это время. Попробуй ещё раз.

--
Axel,
www.axel.drupal.ru

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

--
Axel,
www.axel.drupal.ru

Поробую в скором времени обязательно

Возможные варианты развития модуля:

- генерация статики для выбранных типов нодов (а не только собственного типа static)
- импорт статических сайтов в друпал с сохранением их структуры (друпал получается как надстройка над статическим сайтом, позволяющая изменять его страницы)
- переработка основного движка для более полной поддержки статики: хуки на изменения блоков, генерация прямых ссылок на html-страницы, минуя друпаловский механизм обработки urlов

--
Axel,
www.axel.drupal.ru

Разработчики лучше бы действительно, озаботились GZIP-компрессией и убрали "всё лишнее" из кода (лишний текст, сократили бы число запросов к БД)... а это всё костыли...

Но если нет ничего лучше, то это конечно, тоже вариант. Во всяком случае, "лучше, чем ничего"... "как там создатель Линукса говорил"... хех... а вообще, по моему, можно было бы реализовать другой вариант... который, по моему реализован в большинстве форумов (Invision) и тд...

Зачем создавать реальный html файл? Ведь на его создание опять же требуются время и ресурсы. Не проще ли изменить систему кеширования документов? Она явно какая-то странная...

"Но есть задачи где хранение в БД вообще нафиг не сдалось. Но нужна категоризация контента и т.п."

Такое есть... Например, перевод движка... зачем он в БД, я не понимаю... или хелпы - тоже самое... Вот если бы это всё удалить из Drupal, добавить поддержку разных кодировок ещё, то цены бы ему не было...

Какие такие ресурсы тратятся на создание файла? Ведь это происходит только при его создании/редактировании пользователем. Далее мы имеем просто html-файл на диске, который отдаётся не движком, а сразу вебсервером. Это практически полностью статический сайт. Тут даже количество запросов на создание страницы не играет роли.

Для примера см. как работает такая система http://cmsmadesimple.org
Но она весьма примитивна в плане структуризации контента, с друпалом же мы получаем такую же скорость + мощные механизмы структуризации.

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

--
Axel,
www.axel.drupal.ru

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

если бы их можно было решить... тогда, почему бы и нет? например, почему для всех этих действий вышеперечисленных, не иметь в БД всё-таки "нестатичный" документ, а? будет просто два документа... один выдаётся везде "где это возможно" (статичный), а другой "там где первый выдать никак нельзя" (динамичный)... ну и с темами надо что-то придумать...

например... темы ведь используют css? В таком случае, жаль, что в Drupal нет его стандартизации... жаль, что "все кому не лень" вводят новые теги, новые id и классы для тегов... гораздо лучше был бы стандартный css (а в разных темах просто меняли бы значения классов и идентификаторов) , в этом случае, этот модуль был бы значительно эффективнее. Ну и модулем его было бы хорошо оформить...

PS! А как продвигается работа над Drupal Wiki и Aqua Forum?

Да ничего странного тут нет. Просто идет речь о небольших сайтах, в которых в принципе, CMS нужна для удобного и оперативного изменения контента. Пример: http://stas.akifa-oniks.ru
Сильно не критикуйте, это проект и контента ваще нет :-)
Но на данном ресурсе такая фича нужна, помоему.

"Пример: http://stas.akifa-oniks.ru"

для версии 4.5 есть модуль гостевой книги... по-моему, хороший модуль...

это уже 4.6

Интересно, а как ты всё это вообще хочешь получить от статической страницы? И рыбку съесть и на ёлку залезть... Идея модуля - максимум скорости. Остальным ради этого можно пожертвовать. В тех случаях когда пожертвовать нельзя, надо переходить к динамической генерации контента.

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

Примерно так модуль и работает. Документ хранится в БД, копия на диске. Для teasers выдаётся из БД, html-файл только когда выдаётся полная версия документа. Тут в общем разные вариации возможны.

Вообще-то это и есть модуль, если ты не заметил :) Зачем нужны доп. ограничения с CSS я не понял. Это как если бы с темами завязаться на один единственный шаблонный движок. Кстати, в друпале есть уже один общий дефолтный CSS и то от него стараются избавиться - drupal.css который.

Своим чередом :)

--
Axel,
www.axel.drupal.ru

вопрос:
$ patch -p0 bootstrap.patch
$ patch -p0 block-module.patch
как это из-под Денвера сделать?

patch - утилитка из unix'а
если ты под виндой поставь Cygwin и там поставь patch
и будет вам счастье...

! http://drupal.ru/node/252
--
USU-Lug http://usu-lug.org.ru

видимо надо патчить (как? см. выше) - у меня было то же самое

Хм, действительно :\ Не нужен этот патч, модуль block не содержит изменений. Достаточно bootstrap.inc.

Буду адаптировать модуль к 4.6 - ещё раз проверю как что работает.

--
Axel,
www.axel.drupal.ru

http://www.hivemindz.com/project/staticHTML

искал одно а нашел вот это :) может в разрезе данного обсуждения это кому-то будет интересно

Axel:"Буду адаптировать модуль к 4.6 - ещё раз проверю как что работает".

Как дела с этим модулем? Есть вариант для 4.6? Или уже на 4.7 замахнулся?

В модуле не было надобности, и слишком много ограничений вылазит в такой модели, разработка застыла в том виде как описано в этом анонсе. Однако ввиду появления AJAX в Drupal 4.7 появляются перспективы - статическая генерация страниц + динамическая подгрузка отдельных блоков. Буду пробовать под 4.7.

--
Axel,
Darcs-репозиторий разработок для Drupal

Это позволит увеличить производительность?

Перевод под 4.7 позволит увеличить гибкость этого решения. А сам модуль конечно повышает производительность сайта, ведь html отдаётся вебсервером вообще без участия php.

--
Axel,
Darcs-репозиторий разработок для Drupal

Было бы интересно... да и вообще создавать "полные копии" сайта в html - очень заманчивая идея...

есть обновления/изменения?

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

Народ интересуется: зачем нужен изват, и почему нельзя руками создать чистый html, а в drupal ссылки на этот файл? При грамотной верстке html за 5 мин делается..======================================================
Документация,Дизайн,Переводы

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

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

Вот допустим есть блок "Последние статьи". Содержимое блока обновляется, допустим, каждые два часа. Остальное время - статичный блок. Ты его будешь сам менять каждые два часа?
Понятно, что система его кэширует, но чтобы взять из кэша, она обращается в БД. Модуль избавляет систему от этого обращения, заставляя вмечто запроса просто вставить кусок html.

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

а тем, кому не нужны извращения, лучше работать с блокнотом и чистым html сразу... и вики им тоже не нужна, поскольку - это тоже изврат...

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

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

так - то оно так, но mysql тоже "заточена" что-бы кешировать в памяти и Dries проводил эксперименты оправданности такого способа - разница была очень маленькая, по этому он сделал вывод что нет смысла выностить небольшой кусочек кеша в отдельные файлы:

http://drupal.org/node/45414#comment-67318

"I ran some benchmarks and the average page request time goes down from 140ms (database caching) to 139ms (filesystem caching). That is 0.7% improvement. This confirms my statements: the design is flawed and the complexity is not worth the gain.
(Serving the exact same file as a static page without intervention of PHP, takes 2.10ms on average.)"

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

Сейчас то же самое делает модуль boost. Очень хорошо, что у автора нашлись силы довести идею до конца.

--
Администратор сайта «Drupal — Россия»
на вопросы по Drupal отвечаю только на форумах, не пишите в почту и приватом!

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

Нет. Время хранения в кеше для всех страниц общее. Это мне тоже не нравится. Какие-то страницы можно перегенерить часто, а какие-то хотелось бы положить один раз в кеш и забыть про них на месяца.

--
Администратор сайта «Drupal — Россия»
на вопросы по Drupal отвечаю только на форумах, не пишите в почту и приватом!

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

Не согласен. Не все так однозначно.

1. Обычно сервер БД находится на более мощной (чем web) машине.
2. Он заточен под быстрые операции чтения. Т.е. один простой (из одной таблицы без всякого там комбинирования) запрос для него мало что стоит.
3. У сервера БД есть кэш в памяти, поэтому запрос может быть обработан вообще без чтения данных с диска. Т.е. при частом обращении на сайт обращения самая популярная часть таблицы 'cache' разместится в памяти и все будет работать крайне быстро.

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

Вообще... Это сейчас популярная архитектура, когда делается тупой web-сервер, который ничего не умеет, кроме того, как принять данные от пользователя и вернуть результат, потом этот сервер передает входные данные на Aplication Server, который занимается их обработкой и, если нужно, то обращается к серверам БД, затем AP отдает ответ web-серверу, которому остается только обернуть данные в нужную обертку.
Такая архитектура очень хорошо себя показывает в масштабных проектах (распределение нагрузки рулит).
Дак вот... в Друпале web-сервер и Aplication свален в одну кучу.
Поэтому, я не считаю, что идея хранить все данные в базе данных однозначно плохой. В конце концов, хранить данные прямое назначение Базы Данных.

"Не согласен. Не все так однозначно."

можно сколько угодно говорить абстрактно... но факты говорят о том, что простые статичные страницы отдаются сервером быстрее и с меньшими нагрузками... это также к вопросу о том, почему операционные системы ДО СИХ пор хранят файлы в файловой системе, а не в базе данных... именно потому, что база данных - это именно база ДАННЫХ... но не содержания...

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

> операционные системы ДО СИХ пор хранят файлы в файловой системе, а не в базе данных...
Вообще-то современные файловые системы являются базами данных :) Только заточеные на определённый вид данных (хотя это не обязательно - у некоторых есть возможность тегирования). Журналирование - транзакции, связи не находишь?