Еще один взгляд на кэширование на Drupal

[@XaosSintez]

В общем-то достаточно стандартные советы, в своих проектах так и делали. Но — все равно спасибо, все грамотно и по полочкам

[@totosarg]

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

[@UrbanRider]

Было бы не плохо, чтобы вы добавили в начале топика ссылку на прошлую статью.
А так, спасибо.

[@totosarg]

Добавил, спасибо за совет.

[@slavik]

А еще кеширование блоков, сессий и всего-такого в мемкеш

[@vovochka404]

Может кто скажет, зачем использовать друпал, если он из коробки предоставляет такие проблемы?
Я не слышал ни одного хорошего отзыва об этой cms, но это никак не влияет на ее популярность.
Мистика? Или этому есть разумное объяснение?

[@stalkers]

А разгадка одна — благодатность.

Drupal является очень удачным конструктором, из которого при желании можно собрать всё, что угодно, т.к. система обладает прекрасным API. К тому же, существует куча уже готовых модулей, которые дают возможность собрать сайт вообще не написав ни строчки. Если же писать ручками всё-таки приходится, то кодить зачастую приходится легче, чем при реализации такого же функционала на других CMS.

Недостатки у системы, естественно, есть, и прожорливость ресурсов стоит, наверное, на 1-ом месте, но проявляется этот недостаток разве что для действительно навороченных проектов.

[@egorinsk]

Друпал — кривая, устаревшая система, которая написана программистами-неумехами, которые даже ООП не осилили, используют функции и глобальные переменные (бывшие Сишники?). Система хуков, в которой предлагается определить свою функцию, и переписывать SQL-запросы перед их выполнением, как бы говорит нам о полной индусорукости разработчиков (а у индусов нет ни чувства вкуса, ни чувства прекрасного). Плохо прикрученный сбоку кеш, который сам не обновляется при изменениях в админке. Ах да, по умолчанию кеш использует БД: снижаем нагрузку на БД с помощью БД ))

Ну и SQL запросы радуют (в модуле locale вроде такой есть, для перевода строк):

SELECT s.lid, t.translation, s.version FROM {locales_source} s LEFT JOIN {locales_target} t ON s.lid = t.lid AND t.language = '%s' WHERE s.source = '%s' AND s.textgroup = 'default'

Вообще, хранить переводы строк в БД — сомнительная идея, а еще и делать поиск по полю VARCHAR, или TEXT — это уже вообще на грани бреда. Разработчики Друпала не знают элементарных вещей.

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

[@Negor]

Так укажите другим правильный путь — назовите CMS, приближающуюся к идеалу.

[@Evengard]

Мне тоже интересно, кстати

[@taldy]

которые даже ООП не осилили

да, часто упоминаемая проблема, но такая ли страшная на практике? Вам не нравится как работает или вы за «чистоту рядов»?

А причины почему не весь Друпал на ООП просты: он развивается давно и улучшается эволюционно, а не переписыванием с нуля от версии к версии. Это кстати, сильно облегчает миграцию как проектов так и модулей. И до совсем недавнего времени Друпал поддерживал PHP4, а там вы знаете ООП был «не очень». Теперь не поддерживает.

А ООП там все больше и в ядре и в модулях, посмотрите на Views, на Entity API.

[@totosarg]

Я к друпалу никакой жаркой любви не испытываю, однако, живу в мире, где редко есть возможность что-то начать с нуля (особенно в корпоративном мире). Будь у меня возможность, я бы никогда в жизни не стал делать большой проект на друпале. Но, меня нанимают на работу, на которой, увы и ах, используют друпал. У друпала полно проблем, и как здесь уже написали они связанны с тем что система мощно-универсальная. Именно из-за того что система пытается быть универсальной
она теряет в производительности. Но с вами тоже согласен, в друпале бреда много :)

[@Negor]

Спасибо за статью, но статья не понравилась. Хоть бы цифры какие привели. что-ли. Наподобии «до» и «после». А так ваша статья — беглая заметка котрая понятна узкому кругу людей.

[@totosarg]

И вам спасибо, скажите, а вот лично вам, какие бы данные помогли сделать статью более понятной?
Какие данные вам бы хотелось увидеть в «количественном» измерении?

[@Negor]

Допустим время генерации страници без перечисленных методов кэширования, и с их применением.

[@totosarg]

Вопрос не корректный, как мне кажется. «Время отображения» это комбинированное понятие, там и количество и скорость обработки JS браузером, и качество соединения и т.д. Как вы предлагаете рассчитывать этот параметр? Как интервал от запроса до полной загрузки всех ресурсов? (будет зависеть от вашего соединения в том числе, а еще есть скрипты которые загружаются со сторонних серверов, и время их подгрузки еще и от стороннего сервера начинает зависеть). Вообще, смысл кеширования, при всех прочих равных, не столько скорость, сколько увеличение пропускной способности. Тут уже достаточно легко все измеряется:
Без CDN сайт падает на 3000 единовременных пользователях. С кэшированием в CDN и частичными запросами на родные сервера (см. проблему номер один в статье). Можно удержать примерно 5-6 тысяч человек. При полном кэшировании в CDN, наш сайт спокойно пережил прямой линк с yahoo.com (трафик был в раене 20000 единовременных пользователей на сайте в течении 2,5 часов). Это обусловленно тем, что при кэшировании в CDN, большая часть запросов не приходит напрямую к вам на сервера, а бслуживается серверами CDN'a.

[@totosarg]

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