26 ноября 2008 в 16:01
http://buytaert.net/consumer-search-using-drupal
Дрис написал о сайте с 5.5 млн уников в месяц - переведен на Друпал. Дрис пишет - I don't know what server infrastructure they run on, but with the help from Jeremy at Tag1 Consulting, they configured Drupal to rely heavily on memcached and Drupal's built-in aggressive caching mode. Knowing Jeremy, they are probably trying to serve cached pages from disk, rather than from the database.
Т.е. примерно - я не знаю, как организована серверная инфраструктура, но по мнению Джереми из Tag1, они использовали жесткий memcache и агрессивный cache mode. Возможно, они организовали сохранение кэшированных страниц на диск вместо базы данных.
Комментарии
эта жесть
мда, консумерсерч бегает шустрее моего сайта
Не заметил этот пост и написал тоже на эту тему:
Вот полный перевод упомянутой статьи Дриса: http://buytaert.ru/consumer-search-rabotaet-na-drupal
PS. Я так понимаю, что очень многое зависит от того, как настроен сервер. А если кто-то хочет взять голый Друпал, поставить на шаред хостинге и иметь большую посещаемость - то это смешно.
Для действительно большого проекта - только выделенный сервер и грамотная настройка сервера, а не настройки по умолчанию на шаред-хостинге. Хотя опять же хостинги разные бывают.
Конечно, есть страницы которые последний раз обновлялись в 2007 году. Ой, пардон нашел 1969 год.:) consumersearch.com/cd_players
Почему бы их не записать в дисковый кеш?
Свой сервак никогда не помешает:)
-1 Морда не прошла контроль у валидатора. 40 ошибок.
Не понял, а зачем им регистрация?
Я зарегился 25 под adminом
О-о ....каккая жуть с дизайном произошла. Вах-Вах...
Блин, кухарка делала дизайн
Ломанул сервачок???
Есть к чему стремиться
Други мои.
Друпал это прежде всего АПИ.
нет такого понятия поставил друпал и построил на нем высокопроизводительный проект.
есть понятие построил проект правильно используя друпал апи.
Все зависит насколько глубоко вы понимает друпал.
Пример - стандартная система кеширования друпала НИКУДА не годится. Уже хотя бы потому что она ориентируется на анонимного пользователя не владея информацией об актуальности данных. Владея cache api и понимая КАКОВА должна быть актуальность собственных данных можно выстроить систему кеша ГОРАЗДО более эффективную нежели базовую.
Не говоря уже о том, что можно построить фундаментально свою собственную систему кешированя.
Поймите, использование views cck и прочего это не есть ДРУПАЛ ВЭЙ. Это всего лишь демонстрация того что можно сделать используя дурпал.
поддерживаю предыдуший пост.
мм, это все хорошо, только почему бы разрабам не задуматься об этом - о производительности.
Ну, почему надо руками все лазить, мерить. Почему нельзя сделать модуль - который собирал бы статистику сайта и предлагал бы пути оптимизации.
Я конечно понимаю "почему". Это же опенсурс, на чем же зарабатывать, если все и так работает
Ненужно лазить руками. Возможно Вам пора использовать в своей работе интегрированные среды разработки вроде Zend или komodo где Вы бы получили всю необходимую Вам статистику. И даже больше.
Кроме того, если я ничего не забыл, модуль devel так же предлагает статистику по загруженности страниц.
Вопрос же оптимизации в общем случае не стоит если Вы владеете архитектурой системы.
Я не уверен, что владею архитектурой системы, но оптимизация меня очень интересует.
Подскажите как в этом разобраться.
Интересует кеширование и производительность.
девел вам ничего не скажет. Девел это просто градусник. Причем со шкалой, но без точки осчета
Ну покажет он, загрузка страницы n-милисикунд и что?
Опускаем такие очевидные вещи как оптимизация свои sql запросов, оптимизация кода, и серверной площадки. Также опускаем вопросы связанные с использованием стилей и джава скриптов - об этом уже говорилось не раз.
Если говорить именно о возможностях самого дурпала то первое о чем стоит прочитать это
http://api.drupal.org/api/search/5/cache
а именно в сторону функций cache_set cache_get cache_clear_all
Как простой пример. Любой мой блок или страница в общем случае всегда начинается со строк
if ($cache = cache_get("my_cache_id", "cache")) {
return cached->data;
}
тут код самого модуля по формированияю контента в $output
cache_set("my_cache_id", "cache", $output, CACHE_PERMANENT)
return $output;
В местах, которые влияют на изменение вывода блока стоит
cache_clear_all("my_cache_id")
Производительность
откажитесь от таких монстров как виевс с ццк. И формируете необходимый контент самостоятельно. Самостоятельно описывайте ваши типы нод, самостоятельно формируйте шаблоны.
Так же лично я отказался от phptemplate шаблонизатора в сторону смарти который оказался значительно производительнее первого.
Далее, всегда следует помнить о том что такие вызовы как например node_load или taxonomy_select_nodes КРАЙНЕ ресурсоемки. И если это возможно обращаться к базе напрямую для получения необходимых вам данных.
Такими простыми методами вы можете ускорить свой проект в разы.
следует помнить что приемлемым временем считается загрузка страницы менее чем 0.5 секунды.
например главная страница сайта ubuntu.com грузиться в среднем за 418мс. Как помним сайт убунту сделан на друпал.
ну в общем Вы правы. Из этого вывод можно сделать только то что страница слишком долго грузилась. А то почему не скажет.
Потому и говорю, используйте интегрированные среды разработки. Где Вам наглядно в виде графиков покажут время выполнения по каждому скрипту который выполнялся во время формирования страницы.
Напомню, что одна из рекомендаций автора друпал, это научиться пользоваться отладчиком и попробовать пройти хотябы попроцедурно всю ветку формирования какой нибудь простой ноды.
Из этого вывод можно сделать только то что страница слишком долго грузилась
И это Вам не скажет девел. Откуда известно сколько милисикунд "долго" а сколько "нормально". И что делать, даже если знаете что "долго"
В общем, на орге есть некие советы по оптимизации SQL, есть сервис webo.in, есть в фоксе firebug и тд. Все разрознено.
Конечно, в некоторых случаях проще купит более мощный хостинг
phptemplate vs смарти
где почитать подробнее сравнения.
кстати smarty темплейты для 6ки есть?
Мне они нравятся, в пятерке пробывал, но помоему проект (интеграции данной темплейт системы) малость застрял в развитии
Общепринятый стандарт - генерация страницы не более полу секунды.
Не понимаете как оптимизировать Ваш собственный код - экспериментируйте и используйте отладчик.
Документации о оптимизации sql запросов в интернете Выше крыши. В том числе никто такие вещие как explane в mysql сервере не отменял.
немного тут.
http://drupal.org/node/63210
Если у Вам будет нечем заняться попробуйте одну и туже тему для самрти и пхптемплайт. Та же админка визуализируется заметно шустрее.
Если судить по 5 то почти любой шаблон phptemplate переделывается под смарти в течении короткого времени. Иногда достаточно и получаса.
Застрять в развитии он не мог. Друпал theme api для смарти реализовано и в 6ке в полном обьеме. http://drupal.org/project/smarty
Сам по себе смарти шаблонизатор развивается "семимильными" шагами.
http://smarty.net/
Ок. От Views я отказываюсь почти всегда в пользу сниппетов, которые формируют вывод, а как обойтись без ССК? Иначе как писать свой модуль и мысли не приходит...
Ну так верно. Писать свой модуль, со своими типами нод. Самый производительный способ. (В смысле проект будет производителен)
Конечно это дольше чем просто строить в cck, но выгоды от производительности, на мой взгляд, перекрывают потраченное время.
Да - скорость на ConsumerSearch реально впечатляет !!!
Demimurych - неужели там обошлись без Views и CCK ?
Ок. Я делал вместо связки CCK+ImageField+ImageCache сниппет и в блоке показывал нужные мне анонсы. Кроме того, в phptemplate.php кое-какие функции выносил.
Но свои типы нод я программно не определял... Есть к чему стремиться.
Подскажите мануал про то как грамотно написать свою замену Views. Если точнее интересно как формировать вывод списока нод тизерами (наверно опять же лучше не используя нод_лоад). Лучше на русском, но можно и на английском.
Точно Вамс кажут только разработчики. Я прошелся по нескольким их страницам "внутри" следов как минимум views не нашел.
Не понимаю что Вам пугает в этом?
Составить самостоятельный шаблон, и горда более сложный чем может виевс дело простое.
Есть, на мой взгляд, хороша книга на русском о друпал 5. Где эти базовые вопросы раскрыты очень хорошо.
У нас сейчас сдача двух громадный проектов. Как сдадим, а это к НГ, так и напишу пару вменяемых хаутушек.
Вандюк и Вестгейт. Руководсво по разработке CMS? похоже я пропустил этот раздел, пойду перечитаю.
Нет, стандартная регистрация. Admin Был свободен.:)
Там на сайте недоработки по администраторской части(детские болезни) причем некоторые могут заломать сайт и вывести из строя на некоторое время.
Могу перечислить модули которые там установлены.
system
cs_switch4_theme
actions
admin_menu
adsense
advcache
content
nodereference
number
optionwidgets
text
imagefield
amazonian
cs
cs_solr
tinymce
googleanalytics
imagecache
memcache
path_redirect
php_errors
relatedlinks
transliteration
user_import
views_bulk_operations
pathauto
cs_specs
cs_wheretobuy
xmlsitemap_node
xmlsitemap_term
auto_nodetitle
fieldgroup
token
views
csearch_tweaks
globalredirect
+1
Разумеется, стремиться нужно к безопасности сайтов. Но в данном случае это обычная неправильная(или наоборот) настройка сайта - нет запрета на регистрацию новых пользователей. Там особо ничего и нет. Только при входе под логином другой дизайн, наверное для админов.
У них наверное нянька приходящая.:)
У них ВЕСЬ кеш располагается в ОЗУ =). Сайт поднят на Drupal-5, FreeBSD-7, MySQL-5.0, eAccelerator, memcached и Netscaler, который кеширует .js, .css, и картинки.
Вот бы Drupal.ru такой сервачок!
Золотые слова.
Вот все кричат views, views!!! А ведь это не последние тормоза в Друпале.
Views, конечно прибавляет тормозов, но если даже взять просто вывод списком по термину словаря, то там то же все не очень оптимально.
Даже обычную выборку по словарю таксономии можно ускорить достаточно сильно (я имею ввиду БД). Но, однако, не без ограничений.
Вот немного подробностей этой проблемы:
Допустим у вас в списке выводится 20 материалов.
К каждому из этих материалов может применяться свой формат ввода.
Весь фокус заключается в том, что сначала материалы загружаются в список с использованием node_load() - это 20 запросов, а потом еще загружаются фильтрованные результаты тизера из кеша фильтров - это еще 20 запросов.
Если мы запретим использование фильтрации в тизерах, то сможем дернуть все материалы одним запросом.
Итого считайте - минус 40 запросов.
оокей, убираем views+cck
оокей, целиком убираем node_load из сниппетов. Box php code - превращается в лапшичку.
ооокей, убираем phptemplate заменив на smarty
что получаем? получаем голую структуру, средненькую архитектуру (ну два года назад - она меня полностью устраивала, сейчас - есть вещи гораздо лучше в плане mvc, блочности компонентов), проигрывающую многим фреймворкам form api (отсутствие всяких мелочей типа pre-filter'ы, качественных "быстрых" валидаторов типа alpha|length:3-20|credit_card), не интуитивную админку (которую надо долго готовить, чтобы она стала более-менее удобной для среднего редактора).
Ах да, еще у нас идеология drupal theme layer смешивается немного со smarty (sections, include, modificators) - опять же каша.
И оно вам надо?
По-моему вся мощь друпала сейчас именно в нагенерированном юзерами коде, и великолепным традициям качества кода. Не нравится - так поднимите голову, возьмите zf, посмотрите symphony, cohanaPHP там, web2py, ror, подумайте уже о своей CMS 
не соглашусь немного с последним оратором.
Я сам использую smarty. Очень хорошо позволяет избавится от смешания php кода c html.
Он смешивается правда с smarty кодом
Что касается расширение smarty нужным функционалом - это очень просто.
Кстати не документировано но полезно - выозов theme_links в смартив выглядит так:
{drupal theme="links" links=$primary_links attributes=""}
в сравнение для phptemplate
<?php print theme('links', $primary_links, array('class' => 'links primary-links')) ?>
Да и template.php прекрасно работает в Smarty engine.
Что касается применение сниплетов и views+cck то этот путь для основного обьема сообщества, которое не хочет вникать в програмирование (да оно им и ненадо) и заказывать оное у спецов.
И друпал абсолютно не теряет, для меня как програмиста, своей привлекательности при вычеркивании вышеперечисленых пунктов. Хороший API, хорошоая документация, продуманная архитектура. Вообщем для меня drupal отличный инструмент, база, фреймворк - для создания производительных, прогресивных сайтов.
Вообщем каждому свое. Те, кто хочет нормальный сайт с серьезной посещаемостью и адекватным поведением drupal - тратит на это деньги, другие используют сниплеты, views и cck.
У них ВЕСЬ кеш располагается в ОЗУ
а сколько нужно ОЗУ? чтобы весь кеш туда скинуть?
Запостил инфу на блоге Дриса, там тоже все спрашивали, на чем поставлено сийё чудо.
Боксы описываем своим модулем. Сниппеты зло.
С какой стати?
При идеологически верном верном написании кода, стандартная друпаловская админка(и любая другая) покажет мой код так как нужно.
Тоже неверно. Смарти можно использовать точ в точ как и phptemplate. С той лишь разницей что смарти Быстрее
А при чем тут пользователь?
При использовании "моего" подхода для пользователя все так же прозрачно.
Или Вы о модулях? Тогда я Вас отошлю к 7 ветке. Если Вы следите за ее развитием то знаете что большинство модулей придется СИЛЬНО переписывать. И это еще не учитывая факта что очень много хороших модулей не портировано на 6. Иначе говоря разработчиков не сильно интересует обратная совместимость с нагенерированым пользователями.
И в догонку.
Посмотрите все известные большие сайты построенных на drupal. Ни на одном из них нет следов ни виевс ни сск.
да, это так.
лично мне не мешает php код в темплейтах, лучше следить за смешиванием бизнес кода и кода отображения. Ну это дело индивидуальное. В плане синтаксиса smarty однозначно приятнее, я говорю про то что много чего в нем дублирует функционал drupal theme layer.
причем тут ваш код? я говорю вообще про админку, лично мне для 90% сайтов больше подойдет иерархическая структура, админка в стиле modx/silverstripe с деревом категорий сайта _гораздо_ интуитивнее для большинства сайтов и большинства пользователей, эти сайты использующих. Да даже само разделение листинга нод и add node - не логично. Таких мелочей набирается очень немало.
факты пожалуйста. с чего это откомпилированный код смарти быстрее чем код темы в phptemplate, который сам уже - чистый адекватный PHP код?
пока это все очень голословно.
вы там сверху давали ссылку http://drupal.org/node/63210 , в котором никаких реальных доказательств магической скорости смарти нет.
не надо только думать что я smarty не люблю потому что не пробовал, пробовал и писал под него кучу кода, и тестировал и фиксил, поэтому и заинтересовался что вы там за супер перформанс нашли. Мужики-то не знают!
"все так же прозрачно" для _вас_. в 2006 году тоже так думал
мне самому эти views тоже особо не сдались, если смотреть только себе под ноги - _гораздо_ проще сделать два sql запроса к базе в своем модуле и отрендерить через theme('list'), правда?
это все шапозакидательский подход, типа "да че я буду сейчас изучать этот конструктор запросов (views), наворотили тут понимаешь для дурачков".
попробую объяснить плюсы views, которые еще видимо многие для себя не совсем осознали.
Главный плюс views в том, что это уже какая-то стандартизованная платформа, и это означает одну важную вещь - любой профессиональый друпаллер может зайти на сайт, созданный другим друпаллером, и понять, что если он видит листинг товаров, то он однозначно строится через views. Ему не надо лезть в ваш super_custom_shop.module, в котором у вас там свое ноу-хау парсинга аргументов и пара очень крутых ООП классов, или html вперемешку с php. Он заходит на site building -> views и находит там shop/list. и все. Вся структура у него перед глазами.
Это просто фундаментальный шажок от наколенного написательства до Фреймворка с большой буквы.
я никого не убеждаю что именно этот подход единственно верный, я не отрицаю что у cck и views есть проблемы с производительностью, но и возводить в абсолют идеологию "сейчас все тут сам напрограммлю" тоже не надо.
не знаю что будет на седьмой ветке, увидим. А на пятой и шестой имеем то что имеем, друпал без модулей не был бы так популярен, мягко говоря.
отстраненное наблюдение - мне иногда кажется что проще освоить php чем раскопать некоторые моменты views 2
Че-то умное хотел написать про разрабов, но передумал и стер =). Лучше про процесс разработки напишу.
Есть мнение, что обеспечение обратной совместимости ведет к усложнению процесса разработки и тормознутости конечного продукта. Плюс к этому, - ошибки в реализации АПИ становятся "фичами" и их приходится поддерживать, также для обеспечения обратной совместимости. За примерами ходить не надо, - возмите для примера стабильное апи ядра Windows и плавающее апи ядра Linux.
Теперь о нагенеренном. В модели разработки свободного ПО есть такие ньюансы:
1. если автор не хочет поддерживать дальше проект, то он может передать его другому майнтейнеру;
2. более популярный проект (то есть проект, в развитии которого заинтересованы не только разработчики, но и пользователи) как правило развивается более активно, чем менее популярный проект;
3. на самом деле ньюансов много, но в данном случае этих достаточно для аргументации...
Вывод, переложенный на рельсы Drupal: Если модуль не популярен и не поддерживается разработчиками, то смысл поддерживать такой модуль (из-за меньшинства обрекать на тяготы, упомянутые мною выше, большинство)? Таким образом плавающее API способствует отсеву неиспользуемого или редко используемого кода и реализацию нового функционала с меньшими трудозатратами.
Вы спросите, а что же делать мне если мне нужен именно этот модуль (скажем он написан под D4.7, в свете текущего стейбла 6.6)?
У вас масса вариантов:
1. Юзайте D4.7.x;
2. Портируйте этот модуль (самостоятельно или оплатив услиги программиста) под D6.x;
3. Используйте модуль с аналогичным функционалом (если таковой имеется);
4. Используйте другой движок, так как разрабы вам ничем не обязаны, о чем они честно говорят в тексте лицензионного соглашения.
вот такой он наш свободный мир.
уже хотя бы потому, что смарти НЕ ВСЕГДА перекомпилирует шаблон. И использует свою систему кеширования. Отсылаю Вас на smarty.net за более подробным описанием. В случае же с phptemplate код темы компилируется всегда.
Не правда. Всегда нужно делать выбор, между тем где требуется прямое обращение к базе и использования сущетсвующего апи для него. И это не мое мнение а мнение таких известных разработчиков друпал как например Джон Вандюк или Мэтт Вестгейт. Последний является соучеридителем Лулабот. И занимается тем что консультирует людей о том как проектировать Web сайты.
Вы считаете професиональным качеством умение пользоваться виевс? Удивительно. Мне казалось это в первую очередь знание архитектуры. Вы я так понимаю являетесь представителем той школы программистов которые считают что программирование это елозинье мышкой по монитору. Я пытаюсь донести до Вас мысль, что сам Друпал уже есть стандартизированной платформой.
Модуль написанный профессионалом друпала не требует чтобы для модификации его работы нужно было лезть в его код. Нужно обьяснять что такое slq_rewrite? или использование своих хуков? А то что мы наблюдаем в свалке друпаловских модулей, это зачастую то что написано начинающими в качестве платформы для освоения друпала.
Кроме того, даже процедура _залезть в чужой модуль_ не ДОЛЖНА пугать программиста.
Конечно. О чем и не раз повторялось в начале дискуссии. У Вас проект без претензий к дизайну и производительности, Вам нужно заставить что то работать в максимально короткие сроки - виевс с ццк Вам в руки. Но это не друпал вэй. Это всего лишь демонстрация того что можно сделать используя архитектуру друпал.
Популярность друпала обеспечена не набором модулей. Если сравнивать по критериям - построить быстро из набора модулей красивый сайт со своим дизайном друпал проигрывает почти любой cms. От джумлы до e107. Друпал известен (популерн) потому что, квалифицированные авторитетные люди говорят о нем и его используют, а неофиты к ним прислушиваются. Друпал известен тем что на его базе построены большие известные сайты. И об этом известно.
Я полностью с Вами согласен. И именно об этом и пытался сказать. Разработчикам плевать на виевс с ццк, (хотя элементы последнего включены в ядро 7 ветки). И именно это должно служить намеком, что друпал это не виевс с ццк. А нечто иное.
конечно. Только я опять же раз за разом повторяю, архитектура правильно написанного модуля для друпал так же легка в восприятии для владеющего друпалом как и виевс с ццк. Другое дело что на освоение виевс не нужно читать книг в вникать как работает ядро. И (о ужас) анализировать какработает ядро. Но тогда какой же это профессиональный друпаллер?
Я лично не подпускаю к проекту ни одного программиста который не сможет мне например рассказать как написать свой собственный код сессий для друпала. Или простенький модуль аутентификации.
Еще и еще раз повторяю - правильно написанный модуль так же прост в понимании.
Именно поэтому рациональное зерно ЦЦК перенесено в 7 ветку.
Конечно. В этом и плюс друпала, что он балансирует между тем чтобы угодить этим и тем. Я бы конечно предпочел чтобы он более стремился к этим чем к тем
Еще раз обращаю внимание к тому с чего началась дискуссия. Данный материал позиционируется как - ОГО а вы говорили что друпал этого не может. То есть множиться миф о том, что друпал низкопроизводительная платформа. И множится это миф как раз теми, кто считает что виевс с ццк это друпал. Кто пользуется чьими то горе советами генерирую кучи сниппетов с node_load.
Я же пытался разделить эти понятия обьяснив - что ничего удивительного в строительстве на друпале производительных сайтов нет. Более того, я развиваю свою мысль и говорю что эти проекты, если они написаны понимающими архитектуру дурпал так же просты в понимании(для других понимающих архитектуру) как и попытки повторить это же в виевс с ццк.
Популярность - это палка о двух концах для такой системы как друцпал. С одной стороны хорошо, большое сообщество стимулирует развитие. С другой стороны, друпал такая система которая повзоляет очень многое сделать разными путями, где самый простой далеко не самый производительный. А чаще всего как раз идут по простому пути. И множат и множат решения, которые работают, но которые скорее вредят авторитету друпала.
+100500.
вы, кажется, не совсем понимаете - я не затрагиваю компилирование смарти вообще.
если бы смарти перекомпилировал шаблоны на каждый запрос сайта, он бы вообще назывался не "smarty" а "kill_your_website_in_5_minutes template engine"
по вашему код смарти во что компилируется, в опкод по типу акселераторов?
никакого выигрыша у ОТКОМПИЛИРОВАННОГО темплейта смарти перед обычным шаблоном phptemplate нет. (Я не говорю про примитивное кеширование уже нарендеренных данных, тут отдельный разговор)
я не буду просто утверждать, - вот тестирование производительности (phptemplate это конечно не PHP mess, приближенно php includes, чуть медленнее)
http://alexeyrybak.com/blitz/lebowski-bench-big.gif
детали по тестированию: http://alexeyrybak.com/blitz/blitz_ru.html
вы так безапеляционно заявляете, что страшно становится. Ну считаете вы, что друпал популярен исключительно из-за своей качественной архитектуры (которая как раз нормально позволяет писать модули) и из-за того что большие дяди его начали использовать - считайте дальше. По мне - это лишь один из критериев, и готовые уже модули тоже один из критериев, причем один из самых важных.
да не бывает все и всегда так хорошо, все равно приходится лазить и смотреть код. Код ядра, код модулей. Отлично написанные модули действительно легко и приятно читать и поддерживать. Я не спорю. Я спорю с идеей "откажитесь от views+cck, это медленно и не по-пацански, правильно все писать самому на голом ядре" - потому что ситуация не такая черно-белая, как вы ее тут выставляете - даже для суперпроизводительных сайтов. На обсуждаемом сайте consumersearch мы видим views+cck (в списке модулей во всяком случае, по исходникам определить сложновато что там используется), или это что-то с моими глазами? да там и smarty нет, пропадут же люди
В первую очередь знание архитектуры, конечно. Но и знание views я тоже считаю важным на сегодняшний день для каждого друпаллера.
да что вы, не надо делать такие легкомысленные выводы, я же не говорю что вы просто не в состоянии освоить views
просто привык смотреть немного дальше, чем под свои ноги, думать что я делаю и зачем, и ценить скорость прототипирования и разработки.
Друпал - стандартизованная платформа. views+cck - такая же платформа, стремительно набирающая популярность, (cck будет в ядре с 7 ветки, и станет полноправной частью ядра Друпала - вы то наверно знаете) и втыкать голову в песок, уподобляясь страусу и считая что это однозначно зло и "не drupal way" - не мой подход
Вы демонстрируете свою неосведомленность в смарти.
Caching: Smarty provides fine-grained caching features for caching all or parts of a rendered web page, or leaving parts uncached. Programmers can register template functions as cacheable or non-cachable, group cached pages into logical units for easier management, etc.
и еще
Performance: Smarty performs extremely well, despite its vast feature set. Most of Smarty's capabilities lie in plugins that are loaded on-demand. Smarty comes with numerous presentation tools, minimizing your application code and resulting in quicker, less error-prone application development/deployment. Smarty templates get compiled to PHP files internally (once), eliminating costly template file scans and leveraging the speed of PHP op-code accelerators.
So is Smarty right for you? What it comes down to is using the right tool for the job. If you want simple variable replacement, you might want to look at something simpler or even roll your own. If you want a robust templating framework with numerous tools to assist you as your application evolves into the future, Smarty is likely a good choice.
Вы читали внимательно сами то что кинули? еще раз прочтите. Тест приведенный человеком не репрезентативный. О чем он сам ЛИЧНО и говорит. Это равносильно тому же что я сейчас ЛИЧНО вам скажу что мои результаты тестированя одного и того же шаблона в смарти и пхм теплейт.
И еще раз перечитайте выше мои цитаты Вам. Станет понятно почему на такой тест нельзя полагаться
Вы не внимательны. Я не говорил что это не по пацански. Я говорил что это один из путей делать производительные проекты на друпал. Кроме того даже рекомендовал использовать виевс с ццк тем кому нужно что то сделать быстро. Главная же моя мысль в том, что виевс и ццк это не дурпал.
Вы как то потеряли нить разговора. Перечитайте пожалуйста все еще раз.
Вы не правы. cck НЕ БУДЕТ частью ядра. Из CCK взяли рационально зерно и внесли его в ядро. Это естественно. НО это не означает что принцип работы ЦЦК был взят за основу работы ядра друпала.
да нет, это вы напутали компиляцию и рендеринг, мы говорим о разных вещах. Компиляция - это превращение смарти синтаксиса в php код, рендеринг - набивание php кода готовыми данными. И то, и другое может кешироваться.
И когда вы начали сравнивать компиляцию smarty и компиляцию phptemplate, это по понятным причинам показалось мне бредом - код для phptemplate никуда компилировать не надо, его надо рендерить.
Про кеширование рендеров в smarty я в курсе -
"(Я не говорю про примитивное кеширование уже нарендеренных данных, тут отдельный разговор)". Разжевываю - чтобы нормально сделать мало-мальски динамичный сайт на таком кешировании, придется логику отслеживания/очистки кеша выносить в бизнес-логику приложения. Т.е. например после регистрации нового юзера по хорошему надо чистить закешированный блок new_user_list, и таких ситуаций будет очень много. Чистка по lifetime - это тоже не серьезно. Расскажите, если вы как-то используете кеширование смарти на более продвинутом уровне в Друпале, мне интересно.
одно дело тест, не репрезентативный или репрезентативный, другое дело - голые слова. Если бы вы дали сводку как на вашем производительном друпал сайте smarty уделывает phptemplate, я бы только поблагодарил за пищу для размышлений.
нет, вы говорили что это _единственный_ путь. Цитирую ваши слова, с которых я не удержался и начал дискуссию:
А то что вьюс и ццк это (пока) не друпал - я согласен, и то что иногда на них замыкаться не надо - тоже. Думаю пора завязывать нашу дискуссию, она начала отнимать у меня много времени. Было интересно пообщаться, в контраст к 99% процентам остальных тем на друпал.ру - "как вывести в блок список таксономии" и "где скачать модуль". Спасибо! Желаю удачно закончить свои проекты и рассказать сообществу о своих ноу-хау
Действительно, дискуссия затянулась ... и самое главное, что она бестолковая - сравнивать phptemplate и smarty не имеет никакого отношения к теме.
Попробую резуюмировать свои мысли по быстродействию
- cck и views не обязательно использовать в связке
- Однозначно рендер-print с своем модуле будет гораздо быстрее любого шаблонизатора
- views вовсе не монстр, а количество запросов всегда можно-нужно контролировать
- node_load это вовсе не один запрос к базе, как писалось выше, а несколько (посему снипеты с циклом по нему + node_view - зло и об этом уже достаточно писалось)
Наблюдения за смарти - давно (пару лет) им не пользовавался, но несколько сайтов и по сей день на нем у меня работают, приходилось даже обновлять версию из-за php.
- Кеш (рендера) вовсе не панацея, хотя изрядно добавляет быстродействия. Если для шаблона много переменных, то вычисление md5 для выбора нужного редера из кеша и подгрузка его с диска(системного кеша) жрет намного больше, чем рендер - профайлеры никто не отменял!
- Компилированные шаблоны smarty, собственно, как и phptemplate лежат обычно в op-code кеше и разницу если и можно отловить тестами, то она нивелируется количеством и сложностью шаблонов.
- Удобство и скорость разработки шалонов зависит исключительно от верстальщика-разработчика и его опыта.
Вам не кажется абсурдным что Вы уже сами в одном своем сообщении стали спорить с самим собой. Речь шла всего лишь о том, что использование смарти как шаблонизатора обьективно может принести прирост в производительности. С чем Вы сами и ниже начинаете соглашаться понимая, что смарти, это не простой шаблонизатор аля phptemplate.
Простите, где там написано слова единственный? Или намек?
Производительность
откажитесь от таких монстров как виевс с ццк. И формируете необходимый контент самостоятельно. Самостоятельно описывайте ваши типы нод, самостоятельно формируйте шаблоны.
Я привел типичный пример шагов которые приведут к существенному увеличению производительности проекта.
как самый простой и примитивный тест
Возьмите две темы. Смарти и пхп темплейт. Поставьте. Зайдите в админку. и по обновляйте страницу. Да хотя бы с секундомером. Если владете более серьезными иснтрументами воспользуйтесь ими. Будете удивленны.
Разумеется. Когда производительность современных серверов позволит выполнять нагруженные проекты с приемлемой производительностью то виевс с ццк прямая дорога. Видимо понимая это, разработчки архитектуры друпал и бурт рациональное из ццк.
Я как человек который много Вас старше рискну без Вашей просьбы дать Вам совет:
Вы за своим желанием постоянно контролировать ситуацию, перестаете слушать собеседника. Более того, любите скатываться к личностям. Провоцируя собеседника отвечать Вам тем же. Задумайтесь, возможно Вы бываете неправы. Ладно если Вы правы, победителей не судят, а если нет?
Загляните в цвс ядра. Возможно там вы найдете мои ноу хау
Demimurych, не вводите в заблуждение людей, которые будут читать эту дискуссию! smarty может, в определенных ситуациях, быть быстрее в выводе информации, но это скорее исключение из правил, особенно в применении к drupal - иначе он был бы основным шаблонизатором в ядре. А вот грамотно продуманное кеширование данных - залог скорости большинства проектов и, безусловно, качественная архитектура.
С моей точки зрения Вы неправы.
Во первых в том что это исключение. Отправляю Вас к документации по смарти и его классу кеширования. Которая Вам четко покажет что не исключение.
Выбор шаблонизатора в друпале (по умолчанию) продиктован другими причинами. Смарти требует гораздо более серьезного изучения. чем пхп темплайт. И это изучение чаще всего обычному человеку не нужно. Потому как с задачами которые решает большинство, с не меньшим успехом, справляется phptemplate. И _если_ и _медленнее_ то не настолько чтобы это являлось причиной отказа от него. Согласитесь большинство верстку шаблона называет - расстановкой регионов, и расстановкой своих переменных.
НО Я понимаю о чем Вы говорите.
Вы пытаетесь сказать что при строительстве выскопроизводительных проектов самым слабым звеном оказывается в большинстве случаев не шаблонизатор. Поэтому ставить такой акцент на выборе шаблонизатора как поставил я не вполне корректно. Признаю это. Тут я скорее перегнул палку.
Абсолютно согласен с restyler - действительно, если убрать из Drupal views, cck, node_load и прочие вкусности - то мы получаем не самый лучший голый фреймворк, гораздо интереснее уж тогда будут ZF или Kohana. Друпал для своих проектов выбирают, имхо, по двум причинам - развитое API (кастомизация в целом) и возможность за небольшое количество времени собрать нужный функционал, прежде всего из-за наличия готовых решений. Железяка не так дорога как время разработки, конечно если смотреть глазами не просто программиста, а с точки зрения выживания и развития проекта в целом.
Можно сделать офигенно быструю вещь, но завтра бизнес-цели скажут что это не приносит денег и нужно срочно пробовать что-то другое. И так по каждой мелочи. Лично по мне правильный путь - сделать стандартными средствами то что требуется с точки зрения бизнес-целей и уже потом, зафиксировав успех проекта, можно начинать оптимизировать - да хоть переписывать с нуля.
Можно сделать офигенно быструю вещь, но завтра бизнес-цели скажут что это не приносит денег и нужно срочно пробовать что-то другое. И так по каждой мелочи. Лично по мне правильный путь - сделать стандартными средствами то что требуется с точки зрения бизнес-целей и уже потом, зафиксировав успех проекта, можно начинать оптимизировать - да хоть переписывать с нуля.
грамотно подытожил
зы: в хроме не работает цитата
Подскажите, где почитать про отладчик?