Pull to refresh

Comments 20

В общем-то достаточно стандартные советы, в своих проектах так и делали. Но — все равно спасибо, все грамотно и по полочкам
И вам спасибо, пост был задуман как дополнение к предыдущей статье, ну и вообще, вдруг кому поможет :)
Было бы не плохо, чтобы вы добавили в начале топика ссылку на прошлую статью.
А так, спасибо.
Добавил, спасибо за совет.
UFO landed and left these words here
А еще кеширование блоков, сессий и всего-такого в мемкеш
Может кто скажет, зачем использовать друпал, если он из коробки предоставляет такие проблемы?
Я не слышал ни одного хорошего отзыва об этой cms, но это никак не влияет на ее популярность.
Мистика? Или этому есть разумное объяснение?
А разгадка одна — благодатность.

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

Недостатки у системы, естественно, есть, и прожорливость ресурсов стоит, наверное, на 1-ом месте, но проявляется этот недостаток разве что для действительно навороченных проектов.
UFO landed and left these words here
Друпал — кривая, устаревшая система, которая написана программистами-неумехами, которые даже ООП не осилили, используют функции и глобальные переменные (бывшие Сишники?). Система хуков, в которой предлагается определить свою функцию, и переписывать 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 — это уже вообще на грани бреда. Разработчики Друпала не знают элементарных вещей.

Единственное, что есть хорошего в Друпале — хорошие комментарии и документация. но это хорошая документация к плохой и кривой быдлокодерской системе.
Так укажите другим правильный путь — назовите CMS, приближающуюся к идеалу.
Мне тоже интересно, кстати
UFO landed and left these words here
которые даже ООП не осилили
да, часто упоминаемая проблема, но такая ли страшная на практике? Вам не нравится как работает или вы за «чистоту рядов»?

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

А ООП там все больше и в ядре и в модулях, посмотрите на Views, на Entity API.
Я к друпалу никакой жаркой любви не испытываю, однако, живу в мире, где редко есть возможность что-то начать с нуля (особенно в корпоративном мире). Будь у меня возможность, я бы никогда в жизни не стал делать большой проект на друпале. Но, меня нанимают на работу, на которой, увы и ах, используют друпал. У друпала полно проблем, и как здесь уже написали они связанны с тем что система мощно-универсальная. Именно из-за того что система пытается быть универсальной
она теряет в производительности. Но с вами тоже согласен, в друпале бреда много :)
Спасибо за статью, но статья не понравилась. Хоть бы цифры какие привели. что-ли. Наподобии «до» и «после». А так ваша статья — беглая заметка котрая понятна узкому кругу людей.
И вам спасибо, скажите, а вот лично вам, какие бы данные помогли сделать статью более понятной?
Какие данные вам бы хотелось увидеть в «количественном» измерении?
Допустим время генерации страници без перечисленных методов кэширования, и с их применением.
Вопрос не корректный, как мне кажется. «Время отображения» это комбинированное понятие, там и количество и скорость обработки JS браузером, и качество соединения и т.д. Как вы предлагаете рассчитывать этот параметр? Как интервал от запроса до полной загрузки всех ресурсов? (будет зависеть от вашего соединения в том числе, а еще есть скрипты которые загружаются со сторонних серверов, и время их подгрузки еще и от стороннего сервера начинает зависеть). Вообще, смысл кеширования, при всех прочих равных, не столько скорость, сколько увеличение пропускной способности. Тут уже достаточно легко все измеряется:
Без CDN сайт падает на 3000 единовременных пользователях. С кэшированием в CDN и частичными запросами на родные сервера (см. проблему номер один в статье). Можно удержать примерно 5-6 тысяч человек. При полном кэшировании в CDN, наш сайт спокойно пережил прямой линк с yahoo.com (трафик был в раене 20000 единовременных пользователей на сайте в течении 2,5 часов). Это обусловленно тем, что при кэшировании в CDN, большая часть запросов не приходит напрямую к вам на сервера, а бслуживается серверами CDN'a.
Простите, нижнее написанно было поутру с просоня, не обратил внимание на то что вы спрашивали именно про генерацию. При использовании CDN, генерация вообще не происходит до тех пор пока запрос не придет на ваш сервер, а придет он только тогда, когда истечет кэш в CDN. А когда придет запрос на ваш сервер то страница отгенерится сервером и отправится в кэш CDN'a. Время генерации не зависит от стороннего кэша, а зависит от того что кэширует сам друпал, и сколько кода и запросов в бд должно быть отработанно перед тем как страница сможет быть отдана запрашивающему.
Only those users with full accounts are able to leave comments. Log in, please.