23 сентября 2010 в 22:05
Предлагаю здесь писать о самых тяжелых и проблемных модулях:
Views
Panel
Pathauto
Список самых "тяжелых модулей"
Главные вкладки
23 сентября 2010 в 22:05
Комментарии
И какие с ними проблемы-то?
Уточните, для каких хостингов «тяжёлых» и в чём «проблемных»?
У меня много сайтов на виртуальных хостингах с Panels, Views. Все сайты с CCK и Pathauto. Я не считаю их тяжёлыми, тем более, проблемными.
drupal
Самый тяжелый модуль называется drupal. А вообще действительно, когда хостинг нормальный о тяжелости модулей как то не приходится задумываться.
Запара начинается, когда нужно делать что-то на хостинге, который выбирали без меня. Тогда действительно Views тяжелит. Но можно сделать на другом а потом просто перенести базу. Как ни странно, Sypex Dumper грузит хостинг меньше чем Drupal.
сниппеты
определили бы критерии тяжести (количество запросов на загрузку, потребляемая память), варианты решения, альтернативы, сравнение... а то пустословие какой-то.
ну тяжелый вьюз, ну и что теперь?
Сколько вешать в граммах?
Теперь кричать: "К А Р А У Л! ХОСТИНГ НАСИЛУЮТ!!!"
Про тяжесть писать не буду, т.к. непонятно что имелось в виду.
Про проблемность:
Views-ковыряться много надо зато и возможностей много
Panel-пока не использовал
Pathauto-поставил и забыл. Все бы модули были такие проблемные
Самый тяжелый и проблемный модуль почти всегда сидит перед монитором...
Если cck и views действительно необходимы, то Panel заменяется темизацией, регионами и тд. От него запросто можно отказаться.
Устанавливая любой модуль, нужно понимать, зачем он нужен и возможно ли обойтись без него.
Про panel согласен, никогда не понимал толком, чем обусловлена его популярность
Панельки позволяют оперативно решать вопросы изменения в структуре без необходимости поправлять шаблон. + в панельках есть механизм кеширования, так что его популярность тем и обусловлена - облегчает администрирование.
Вьюсы стоят на drupal.org
Друпал без Вьюсов и прочих тяжёлых модулей - сомнительная по полезности CMS
Panels - совсем не тяжелый модуль. Это распространенное заблуждение.
как ССК и Виевс...
Панели очень прикольный модуль, я был о нем плохого мнения пока не поюзал его пару раз, его необходимость понимаешь когда у тебя на сайте 20 и более разновидностей страниц, либо у них сложная структура и т.д. посмотрите на http://www.ppr.com или http://www.runewsweek.ru, парни они на панелях, а представляете сколько мозгоруконервотраха на регионах и блоках это делать, а саппортить и админить, этож какой модер должен там сидеть шарящий.
Тем более в панелях под 6-ку товарищ merlinofchaos (кстати папа вьюсов вдруг кто-то не знает) если можно так сказать вложил душу.
Под 5-ку пробовал - не понравилось и забил на него. Попробую под 6-ку.
+100
Ядрёный обвес ... задумался
Попал в неудачное время, у меня нормально отображается :), может ты по диалапу коннектишься
1.shared hosting
2.тяжесть - нагрузка на сервер, количество запросов к бд.
Что шаред хостинг? у меня на шареде есть проектик в котором много всего (ну панелей нету да они там и не надо) http://poroxa.net он конечно не блещет великой посещаемостью, но ресурсу всего 7 месяцев.
Если Вы думаете что вьюсы создают нагрузку на сервер по запросам в БД то вперед учить мат часть. Филдовая вьюха выгребает инфу 1 селектом.
Ичо?
Скальпель может убить, а может принести прибыль. Тут не в модулях вопрос, а в том как ты их используешь
ТС, да не слушай ты этих умников, которые говорят, что Вьюс не является тяжелым модулем.
Страница созданная на Вьюс, например, в полтора раза больше расходует оперативной памяти. А про негибкость Вьюсов я вообще промолчу. Большинство сложных задач в принципе НЕВОЗМОЖНО решать с помощью Вьюсов!
Еще, по моему мнению, тяжелыми/нерациональными являются следующие модули:
Если Вьюсы не гибкие, то тогда что-же гибкое в друпале?
Твой собственный запрос в БД?
перефразирую твой ответ: "Большинство сложных задач в принципе ВОЗМОЖНО и НУЖНО решать с помощью Вьюсов!"
Пример в студию, потом будем общаться.
самый тяжёлый модуль у тебя в голове
А как же ситуация когда на сайте будут десятки тысяч онлайн????
Самый тяжелый модуль System!!!!одинодинодин
Для главного умника, лезем на страницу модулей Drupal.org, где они сортируются по популярности и количеству скачиваний и видим, что первым стоит, как ни странно, Views. Это чём-нибудь говорит?
Миллионы мух не могут ошибаться, он гений, он превзошёл своё время, он слишком умен для нынешних времён, а вы отказываетесь это принимать!
1. Comments
2. CCK
3. Forum
4. Blog
5. Menu
6. Statistics
7. Taxonomy
8. Tracker
9. Profile
10. Search
11. И т.д.
чуть чаем не поперхнулся
зачем друпал если нет этих модулей
чтобы синкора за 20$/час написал их тебе
Акуеть! Профессиональный программист прочитавший Вандюка и всего 20 баксов в час, не ценит он себя, ой не ценит...
А я бы хотел услышать от Синкоры конкретный пример сложной задачи на тему
Да кто ты такой, по сравнению с SINKORA?
Ты Вандюка читал, чтоб так говорить?
Мне достаточно своих тестов.
Так и не спорю, что Вьюсы самые популярные. Но разве разговор идет о популярности?
ТС попросил перечислить тяжелые модули. А ему в ответ заявки типа "какой у тебя хостинг?", "а ведь Вьюсы самые популярные!"... Какая разница какой у него хостинг? Какое дело до популярности модулей? Тема форума о другом.
Станислав Езерский, я тебя не знаю, ты меня не знаешь. Смысл делать необоснованные выводы о том, чего мы не знаем на самом деле? Да и услуги свои я никому не предлагаю, нет такой необходимости.
Вандюк, Вандюк... Знал бы он, как его боготворит Виктор RxB!
Нет уж сударь, сказали "А", говорите и "Б"
Пример тормознутости в студию, в противном случае все Ваши высказывания по поводу вьюсов бред и ничего не стоят.
Я повторял, повторяю и буду повторять для организации выборок информации на сайте использовать только "вьюс" и уже если совсем неразрешимая задача (я за 3,5 года работы с друпалом такой не встречал) то попробовать прицепиться к вьюсовому запросу на хуке (признаюсь честно не помню как называется, но 100% знаю что можно) и уж если и это не помогает то писать свое.
Ичо?
Уже третий или пятый раз приводишь эту цитату... XD
Ну не было у меня еще необходимости реализовывать unit-тесты в Друпале! И что с этого?
А чем плох мой совет новичкам Друпала по поводу чтения книги Вандюка?
Или я еще в чем-то лохонулся, по-твоему? Зачем цитируешь тогда, Вассерманыч ты наш?
Детский сад, хехе...
Я просто хочу стать таким же гурой как ты, ты оптимизируешь сайты где 10000000000 онлайн (пока нет, но обязательно будет), ты даёшь юзарам советы в стиле "Да тут один простой запрос" и в топик больше не приходишь, ты никогда не приводишь аргументов, думаю это признак высокого профессионализма, жаль что у нас в 10-ом классе нет веб-программирования!
Какой пример? Мне достаточно того, что я сам убедился в том, что вьюсы мне не нужны. Я, в принципе, никому не навязываю свою точку зрения.
Мне вот интересно, каким образом будете организовывать логику кеширования на сайте, повсеместно используя вьюсы?
Синкора, как всегда, не в теме
У Views вообще то есть плагины для кеширования и всегда можно написать свой собственный
Ну и на здоровье, пользуйтесь тем, что нравится, ставьте плагины и т.п., как вам угодно...
Комментарий в стиле "не играй в мои игрушки и не писай в мой горшок.". Детский сад, штаны на лямках.
Ты не думаешь, что это ты здесь на сайте "писаешь в чужой горшок" ? ))
Я думаю, что в твоей голове на данный момент ничего нет, кроме эмоций. Поэтому общайся с такими умниками как ты, или с самим собой!
Ну тогда давай без эмоций, выбирай хостинг и любой набор модулей а еще лучше голый друпал с твоим самописом + с моей стороны голый друпал, сск + вьюсы и больше ничего лишнего. делаем задачу вывод статей в определенном виде по определенному урлу, для тебя как для гуру это не составит труда? у тебя условие не использовать вьюс у меня обязательное условие использовать вьюсы и потом тупо замеряем время генерации страницы у тебя с кешом и без и у меня с кешом и без всех делов то.
И вот эти тесты и расставят все на свои места, если принимаешь вызов о великий то называй любой хостинг, я думаю что товарищи из "патрола"(RxB, gor) даже предоставят на 2-3 часа этот хостинг с парочкой доменов, ты же успеешь за 3 часа написать запросы для вывода статей ;).
В общем сударь, если не сцыте то выходите на дуэль, секундантами приглашаются все желающие.
glu2006, отличное предложение!
К барьеру, господа! -)
А не жалко ли вам времени, господа?
Три часа чтоб доказать преимущество вьюсов перед Вашим сударь самописом мне не жалко, я не обеднею на 45 долларов
Называйте время и место.
Ну а вот у меня нет времени на бессмысленные споры и доказательства.
Но если есть такое желание, можете просто привести здесь весь код, который выполняют Вьюсы во время генерации самой простой страницы. Думаю, результат очевиден - Вьюсы проиграют в любом случае...
В общем сударь все с Вами ясно, диагноз "пустозвон".
Не буду объяснять почему и как, оставайтесь при своем мнении, только не надо молодежи его рассказывать просто держите свое мнение при себе.
PS. не знаю сколько бы тебе потребовалось времени на самопис, я рисковал потерять не более 30 минут для решения своей задачи.
Приведите пример своего самого простого самописа, ведь наработок то уже много для "мега проекта", наверняка есть и выборка и вывод информации.
Простецкий пример, придумал сходу:
function my_module_menu() {
$items['test'] = array(
'title' => 'Test page',
'page callback' => '_my_module_test',
'access callback' => 'user_is_logged_in',
);
return $items;
}
function _my_module_test($argument = 10) {
$nodes = db_query_range('SELECT title FROM {node}', 0, $argument);
$list = array();
$output = '';
$argument_i = $argument;
while ($node = db_fetch_object($nodes)) {
$list[] = array(check_plain($node->title));
$argument--;
$output .= _my_module_test($argument);
}
if ($list) {
if ($argument_i == 1) {
$output .= theme('item_list', $list);
}
else {
$output .= theme('table', $headers = array(), $list);
}
}
return $output;
}
Жду решения этой простой задачи через Вьюсы, а также доказательств того, что Ваше решение будет проще и быстрее. Буду также весьма признателен, если Вы распишете код логики работы Вьюсов при отображении данной выборки.
Не совсем понял зачем там рекурсия, что это за чудо вывод информации, если Вам надо вытащить 10 node->title или каким либо образом их сгруппировать, то:
Обыкновенный филдовый вьюс 1й филд node->title, 2-й филд по какому признаку группировать. Далее выбираете себе стиль отображения филдовый или табличный или еще какой нибудь и все.
А логика там проста до безобразия 1 запрос в БД и обработка данных (разматывание выборки), затем подготовка данных на препроцесс функции и вывод через шаблон.
Теперь плюсы: можно прицепится к обработке и выводу контента практически на любом этапе не ломая при этом код самих вьюсов, в Вашем примере этого нет вы даже не удосужились согласно правил кодирования разнести в разные функции вычитку с обработкой и вывод готового html, что уже мне сказало о многом.
+2 кеш как на уровне вьюсов так и на уровне ядра друпала, у Вас этого нет.
+3 если я к примеру захочу тут же сделать поиск по тайтлу, то мне достаточно просто добавить и раскрыть фильтр по contains а Вам придется переписывать свой запрос. А не дай бог туда еще и аякс засунуть а я просто поставлю галочку.
+4 я завтра захочу поменять вывод таблицей на вывод списком или дивами, Вы опять курите нервно в стороне а я всего лишь переключаю радиобаттон.
+5 я нажав всего одну кнопку организую вывод этой информации в любой регион на сайте а вы опять нервно курите и пихаете в блок вызов функции.
+6 в конце концов мне не надо писать ни строчки кода, только если перекрыть шаблон вывода, а Вам надо регистрировать хук меню, сбрасывать кеш, не забыть про пермишены и самое главное не забыть о пунктуации и орфоргафии php не дай бог ; забудете поставить где нибудь.
и если хорошо подумать то таких плюсов моего метода я смогу Вам привести еще столько-же.
Да а вот если Вы захотите реализовать самописькой задачу которую Вам куку выкатил то там я вообще посмеюсь.
Да, чуть не забыл вы в своем примере количество запросов в БД посчитали?
Вот именно, что простецкий, банальности расписывать ума не надо. Ты лучше реализуй пример с отбором нод типа "квартира/машина" по динамическим фильтрам.
У каждой ноды 10-15 CCK-полей (чиловые, текстовые, референсы, имейджы), наверху 5 exposed-фильтров, всё через аякс.
+1. Я тоже, только я подумал что я не проснулся
Чтобы попросить сделать вас такой же рекурсивный колбек на Вьюсах:)
Также там есть динамическая смена шаблонов вывода (таблица/список) - как такое на Вьюсах можно сделать?
Да, да, считал, их очень много:) Но на Вьюсах не меньше будет.
Насчет задачи Куку. Надо будет сделать - сделаю.
P.S. А если в настройках Вьюсов не найдется нужной галочки/кнопочки, что будете делать?:)
Если уж Вам так хочется, то говно вопрос я напишу точно такую же рекурсию на preprocess_view
<?phpfunction phptemplate_preprocess_views_view_(тип и имя вьюхи)_page_1(&$vars) {
$vars['recursion'] = моя рекурсивная theme функция ($vars['view']->result);
}
?>В шаблоне стиля вьюхи:
<?php print $recursion; ?>У меня 1 запрос
Ты это если и сделаешь в лучшем случае минимум за 5-7 часов (не забудь там пару рекурсивных выводов написать), а я за 1 максимум только тыркая по кнопкам из админки, даже php знать не надо.
Вьюс расширяемый модуль и если нужной галочки не будет, то я сяду и напишу эту нужную мне галочку в виде плагина.
А вот теперь сударь попробуйте убедить меня в том что вьюсы говно. Пойми не могут десятки тысяч программистов всего мира ошибаться, вьюс самый популярный модуль друпала.
Для меня лично без вьюсов и CCK друпал унылое говно, а вот с этими двумя модулями он превращается в мощнейшую систему управления контентом.
PS. Я для себя лично сделал вывод, как программист вы пока еще слишком молоды (иначе и у себя обошлись бы одним запросом), я представляю сколько
овночудо кода в Вашем мегапроекте который к сожалению так никто и не видел.А по сему спор с Вами прекращаю в виду его дальнейшего бессмыслия, удачи в прочтениях Ван Дюка (как совет перечитайте его в оригинале и лучше раза 2 или три) и остальных авторов. Удачи в изучении друпала и научитесь признавать свои ошибки и поражения.
Sinkora fail
glu2006, респект и уважуха.
Синкора, вы действительно считаете, что вас просто тут все не любят и обидеть хотят?
Все выше перечисленные "тяжелые" модули реально необходимы и тяжесть их более чем сомнительна
1. Вы обещали обойтись без кодинга.
2. И где же код Вашей рекурсивной theme функции?
3.
Понятно, Ваша рекурсивная theme функция будет точной копией моей функции _my_module_test. Тогда, объясните, в чем Вы выиграете, если одновременно настроите Вьюсы и напишете мой код отдельно от Вьюсов?
3. В итоге, в Вашей рекурсивной функции, так же как и в моей, будет 1 запрос. И при рекурсивном вызове он выполнится 1024 раза, не больше и не меньше.
У Вас же моя рекурсивная функция (сами признались), и это значит, что у Вас как минимум 1024 запроса.
Юрий, я разве писал в своем колбеке что-то подобное на функции cashe_set, cashe_get? Ну? Тогда зачем Вы ставили галочку "кешировать"? У меня же условие было без кеширования!
О, опять кодинг на php - но это же нерационально! Вы ведь утверждаете, что на Вьюсах можно делать функционал "только тыркая по кнопкам из админки, даже php знать не надо"...
Как говорил раньше, я не собираюсь Вас убеждать ни в чем. Это Вы, наоборот, хотите меня убедить, что Вьюсы - это истинный путь Друпал-ниндзи. Но я имею право с Вами не согласиться!
Юрий, знания и опыт - это хорошее дело. Но более важно уметь эффективно применять эти качества на практике, а не на тестовых примерах.
Насчет одного запроса. Повторюсь, Вы написали, что повторили мою рекурсивную функцию - это значит, что запросов типа "SELECT title FROM node LIMIT 0, (переменная)" у Вас ровно такое же количество (1024)!
И уж очень близко к сердцу Вы приняли мой тестовый пример, в котором акцент делался не на количество запросов, а именно на факт того, что рекурсию и динамическую подстановку функций theme('item_list', $list); и theme('table', $headers = array(), $list); Вы не сможете реализовать на Вьюсах "только тыркая по кнопкам из админки"!
Вы действительно думаете, что это был "рабочий пример", и что я фанатик рекурсивных запросов n-го порядка? Если бы мне нужно было это реализовать одним запросом, то я бы это сделал именно одним запросом, а остальной вывод реализовал бы через массив в рекурсии. Но повторюсь, задача была не в этом.
Юрий, Вы так и не решили мою простейшую задачу! Вы прочитали мне целый курс молодого бойца о модуле Вьюс, чего я Вас не просил делать, поскольку базовые знания по этому модулю имею вполне адекватные. И в конечном итоге, не справившись с задачей (если не считать того, что Вы на пальцах прикинули решение), Вы перешли на самое последнее дело - на критику моей личности, гордо уверив себя, xxandeadxx и kodo в своей правоте.
Если Вы когда-нибудь решите эту детскую задачу, то не поленитесь предоставить нам Вьюсовый экспорт Вашего решения, чтобы мы могли это проверить.
А если насчет Вандюка, то в своей книге он о Вьюсах ничего такого и не писал, он вообще про Вьюсы ничего не писал (имею в виду его книги для 5-ки и 6-ки)! И что вообще из моего скромного колбека заставило Вас думать, что я не умею пользоваться API Друпала?
P.S. Юрий, я раньше имел о Вас более лестное представление.
Во первых в споре и изначальном предложении предмета спора не было о рекурсии ни слова, во вторых Вы заведомо придумываете задачу зная что тыкая галочками во вьюсах рекурсию не вызвать это с Вашей стороны как минимум не честно.
Если Вы помните то Вам предлагалось написать самопис выводящий статьи в определенном виде по определенному урлу при чем тут рекурсия? или вы на своих мега проектах новости тоже рекурсивно выводите?
Если Вам так сильно свербит посмотреть на рекурсию пожалуйста:
<?php
function моя_рекурсия($items) {
$list = array();
$output = '';
$count = count($items);
foreach ($items as $key => $item) {
$list[] = array(check_plain($item->title));
unset($items[$key];
$output .= моя_рекурсия($items);
}
if ($list) {
if ($count == 1) {
$output .= theme('item_list', $list);
}
else {
$output .= theme('table', $headers = array(), $list);
}
}
return $output;
}
?>
Ни о каком плагиате речи не идет у меня так и остался 1 запрос в БД, вы еще и в код смотрите сквозь пальцы.
У меня 1 запрос
Вы еще и читать внимательно не умеете задача была с кешированием и без.
Не надо выдирать мои слова из контекста и пытаться перекрутить на свой лад. Я лишь сказал что функционал для решения задачи предложенной Вам для решения куку можно решить не написав ни строчки кода. Конечно встречаются задачи когда надо вмешаться и в препроцесс и в шаблоны или вообще свою функцию вызвать.
Я не пытаюсь не хочу и не буду Вас в чем-то убеждать, потому что вы, как упертый осел доказываете всем что вьюс это плохо и тяжело и что надо писать свои решения и доказываете это в разрез всему сообществу друпала. Вьюс скачивают в неделю 250.000 раз это Вам хоть о чем-то говорит? Или все кругом дураки и только вы такой умный?
Покажите нам свои эффективно примененные практические знания, мои к примеру есть на друпал орге и на записях выступлений DrupalCamp а где есть ваш опыт??? (это конечно попахивает хвастовством, но реально вы меня вынудили)
Ни куда я ничего не принимал. Пример должен быть логичным, это тоже самое что доказывать нахера друпал для вывода надписи "hello word" пусть даже в рекурсии и со 100 запросами в БД.
Вам предложили задачу, так нет вы нашли свое извращенческое и теперь еще что-то доказываете.
Вы сами прекрасно знаете что вашу задачу без вмешательства на хуках не решить. Спор был не о рекурсивности а о тяжеловесности и рациональности использования модуля вьюс.
Вы сославшись на нехватку времени отказались решать мою задачу или задачу куку.
Если уж Вы считате себя хорошим специалистом в друпале, то объясните, почему один из Ваших проектов я специально не выкладываю на него ссылку до сих пор на вьюсах??? (проект литературной тематики)
Если Вы считаете что я необоснованно назвал вас молодым программистом докажите мне обратное, а пока я вижу только бессмысленный рекурсивный пример который даже и применить то нигде нельзя.
Ну и раз уж тут народ больше трется может кто подскажет решение http://drupal.ru/node/51164 Sinkora нука утри нас всех ;).
Если тебе на самом деле приятно чувствовать себя победителем в бою, в котором ты не принимал участия - можешь оставаться в своем возвышенно-эйфорическом состоянии, я лишь буду за тебя только рад.
Нет я так никогда не считал. Я даже не обижаюсь на Вас за то, что Вы не поняли суть нашего спора с Юрием.
супер
хватит писать Вас и Вы с прописных букв, это хуже, чем ты, ей богу!
http://www.gramota.ru/spravka/letters?rub=rubric_88
Я не претендую на премии, но стараюсь писать грамотно (хотя не всегда получается)
Для тех кому лень по ссылке клацать:
С прописной буквы пишутся местоимения Вы, Ваш как форма выражения вежливости при обращении к одному конкретному лицу в письмах, официальных документах и т. п., напр.: Поздравляем Вас..., Сообщаем Вам...
(Лопатин В. В., Чельцова Л. К., Нечаева И. В.. Прописная или строчная?: Орфографический словарь русского языка. М.: АСТ-ПРЕСС, 1999, 50, стр. 34 ).
http://www.artlebedev.ru/kovodstvo/sections/165/
Как по мне, Вы и Ваш еще можно простить в рекламных люзоблюдских обращениях к самым ценным клиентам на свете, или при обращении к ну очень уважаемым людям. Но при общении на форуме это скорее подчеркивает дистанцированность собеседника.
Подтверждение своему мнению встречал на многих переводческих форумах, в правилах перевода. Ну и здесь, например, простите за ссылку на самизнаетекого
А я к Sinkora в друзья и не набиваюсь
Просто "тыкать" я не приучен поскольку водку или пиго с ним на брудершафт не пил и в одной команде не работал, а писать при обращении к конкретному лицу "вы" с маленькой буквы не получается мизинец автоматом "shift" нажимает.
Так что как говорится такова селяви.
Так, а где об этом в документации написано?
По поводу спора "Sinkora vs все остальные" - решил провести свое маленькое исследование
Итак, страница, реализованная с помощью views, отрабатывает примерно за 1.1-1.3 сек, с включенным кэшированием Rendered output - примерно 0.6 сек. То же самое с помощью своего кода (pager_query(), node_view(), theme('pager')) БЕЗ всякого кэширования - ~0.7 сек (+ при когда отключим сам views, доп. выиграем на загрузке модулей в bootstrap, но это я уже не смотрел). Т.е. по времени генерации вроде бы можно добиться с помощью views примерно той же производительности, что и у кастомного кода (правда, во views для этого уже придется включить кэширование). Потребление памяти не смотрел, но здесь наверняка views проиграет.
Теперь подумаем, как можно дальше оптимизировать оба варианта. Свой код - никаких проблем: например, кэшируем каждую отрендеренную ноду, т.е. вместо вызова node_view() будем брать из кэша. А как с views? Не патчить же?
Так что кастомный код тоже не стоит сбрасывать со счетов, другое дело, что сначала лучше не изобретать велосипед, а попробовать подшаманить views.
Посему очень была бы полезна инфа по плагинам кэширования для вьюс
Товаристч
Во вторых никто не мешает вам включить общий кеш и тогда все ноды тоже бедет кешироваться в таблице cache_content
В документации этого может и не быть. Views очень стремительно развивающийся проект и кеш там появился относительно недавно.
Есесно. Речь о том, что за счет больших ресурсов мы получаем отличную гибкость, модульность, расширяемость. А проблему ресурсов нужно решать лучшим железом - оно дешевле, чем труд программиста, пишущего свой велосипед вместо views.
Помимо плагина для кеширования, можно написать свой display plugin, который будет выводить то что нужно, и как нужно. Патчить ничего не надо.
О чем и речь.
Это open source, читайте исходники (плагина time based cache) и поймете. Не обязательно иметь для этого книжку.
Программист должен знать и уметь пользоваться разными инструментами. Он должен знать их сильные и слабые стороны, для того чтобы применять (или не применять) их наиболее эффективно.
Программер умеющий кодить и знающий две-три библиотеки будет подуктивнее программиста, который просто кодит. Думаю это вполне очевидно.
Споры про тяжесть вьюс идут давно, однако противники вьюс, как показывает практика, плохо знают как он работает, плюс пишут свой код достаточно криво. На предложение "посоревноваться" всегда отвечают "мне некогда". Показательно.
Однако. Views не может быть легче самописного модуля из трёх строк, т.к. он работает по всем правилам Drupal (которые очень любят игнорировать начинающие друпалисты): вызывает перед и после каждого своего действия опрос хуков, которые могут изменить его поведение, выводит все данные через слой темизации с шаблонами и препроцессингом и тд. и т.п. Спору нет "print $title;" будет быстрее работать, вот только писать вы его будете на порядок (если не больше!) дольше.
1. Допустим, мне нужны обычные тизеры нод, и я хочу использовать "филдовый вьюс" - в этом случае придется темизировать вывод рез-тов, чтобы они выглядели как тизеры нод? По-моему, такое дублирование темизации несколько кривовато.
2. Даже если это меня устроит, рендеринг такого вью - около 0.4 сек (с включенным кэшированием вью). Тоже не фонтан.
Вы невнимательно читали, я пробовал и с кэшем вьюс, и без.Для того чтоб у вас не было проблем не используйте стандартное поле body оно еще с 4.7 кривое и корявое, сделайте свой сск филд и будет фонтан.
Блин ну почему не стараетесь мыслить на перед???
Все проблемы производительности друпала из-за незнания элементарных вещей.
Вы к примеру знаете что установленный модуль advansed_forum увеличивает время генерации страницы в 10 раз(из-за не проиндексированного tid), всего лишь один индекс в БД по tid который не предусмотрен по умолчанию и его надо просто ручками указать уменьшает это же время в те же 10 раз
Прикольно не правда ли;)
надо всего лишь избегать node_load и вьюсы будут летать.
Мастерхост штоле?
Без проблем, я в личку пришлю
Отправил доступ к хостингу в личку
Вьюсы криво режут поля. Пару раз надо было резать по словам - обрезалось магически криво с разницей в пару предложений и посреди слова, хотя "округление" стояло пословное. Делал руками. В 3-й версии не проверял. В 7-ке текстовое поле доделали и оно теперь может быть "тизерным".
Я если честно ни разу не встречал чтоб вьюсы что-то криво резали в сск, там выполняется на пост обработке точно такой же truncate_utf8 как и вызванный руками.
А вот с боди там иногда творятся чудеса.
вот, на встречер, говорил
что стандартный форум кривой в плане производительности
а вот advansed_forum получше
кстати, tid это поле к чему?
tid - это id термина таксономии.
Ну дык, это-то и странно. Дебажить было лень, поэтому не разбирался, однако факт. Мало того, резало ещё и не по utf, а по ansi, то есть возникали "вопросики" что совсем уже ни в какие ворота. Другими словами как-то там до truncate_utf8 не доходило...
И еще раз повторяю - филдовый вьюс не всегда подходит, т.к. для получения обычных тизеров нод придется темизировать вывод вью, причем дублировать разметку из node.tpl.php, что не есть хорошо. Гораздо логичнее сначала попытаться оптимизировать модуль views вообще.
Что касается кэширования views, тут тоже есть небольшая проблемка. Кэш Rendered output не сбрассывается при обновлении нод, причем ручной сброс через Tools модуля views тоже не помогает - только сброс всех друпаловских кэшей (раздел Производительность). Не спорю - можно сделать сброс этого кэша самому (hook_nodeapi()) - но сам факт. А кэш только Query results производительность не улучшает.
Я все-таки не пожалел времени и устроил сравнение "Views vs. Custom code"
Спасибо в т.ч. it-patrol в лице RxB.
Итак, имеем сразу 2 сборки Друпала с Уберкартом и одинаковым контентом (11 нод типа Product). На обеих сборках реализован постраничный вывод продуктов: на одной - с помощью views, на другой - своим модулем (с поддержкой кэширования).
Результаты тестирования на хостинге it-patrol:
Views, без кэширования, ноды - 0.2 сек, 5 Мб, 147 запросов.
Views, без кэширования, поля - 0.12 сек, 5 Мб, 88 запросов.
Views, с кэшированием, ноды - 0.07 сек, 5 Мб, 49 запросов.
Views, с кэшированием, поля - 0.07 сек, 5 Мб, 49 запросов.
Свой модуль, без кэширования, ноды - см. тест на хостинге-2.
Свой модуль, с кэшированием, ноды - 0.04 сек, 2 Мб, 31 запрос.
Свой модуль, поля - тест не проводился.
* Цифры получались просто - страница вручную обновлялась несколько раз, затем выбирался лучший результат. Расход памяти был получен с помощью memory_get_peak_usage(). Кэширование во Views - Rendered output.
Результаты тестирования еще на одном хостинге:
Views, без кэширования, ноды - 0.3 сек, 12 Мб, 147 запросов.
Views, без кэширования, поля - тест не проводился.
Views, с кэшированием, ноды - 0.22 сек, 12 Мб, 49 запросов.
Views, с кэшированием, поля - тест не проводился.
Свой модуль, без кэширования, ноды - 0.21 сек, 9 Мб, 92 запроса.
Свой модуль, с кэшированием, ноды - 0.16 сек, 9 Мб, 31 запрос.
Свой модуль, поля - тест не проводился.
Мой вывод: по-видимому, на нормальном хостинге абсолютные цифры должны быть приемлемыми для всех вариантов, поэтому лучше использовать views как более гибкое и быстрое в реализации решение.
Если хочется улучшить производительность - попробовать оптимизировать views (см. ниже). Переходить для этого на свой код - выигрыш в абсолютных цифрах получатся небольшим (хоть в относительных и в 1.5-2 раза быстрее), а по гибкости это конечно хуже.
Свой код, похоже, имеет смысл использовать, только если нужно что-то, что нельзя сделать с помощью views.
Правда, если использовать кэширование views, придется писать свой cache-plugin, т.к. в Timebased сброс кэша по изменению нод действительно не предусмотрен (т.е. это не баг). Может кого-то такое кэширование и устраивает, меня - нет. В принципе, там ничего сложного. Ну или, как предлагал Crea, написать сразу display plugin (с этим я как раз сейчас разбираюсь).
Отлично! Спасибо за сравнение.
Пару вопросов: почему в своём модуле не сравнивали с кэшрованием и без? Код модуля желательно тоже прикрепить.
Вьюха которая делает нод лоад не показатель, сделайте филдовую причем с перекрестными запросами, плана node_reference проверьте производительность
Я вообще никогда не использую вьюсы которые делают node_load в них нет смысла поскольку сам по себе node_load кешируемая функция и в этом варианте проще написать свой запрос который выгребет все ниды и потом в цикле размотает.
По поводу node_load для цены уберкарта не ткнете носом где там нод лоад?
если цена в запросе выгребается это кстати вьюха из коробки
node.type AS node_type,
node.title AS node_title,
uc_products.sell_price AS uc_products_sell_price,
node.vid AS node_vid
FROM node node
LEFT JOIN uc_products uc_products ON node.vid = uc_products.vid
WHERE (node.status <> 0) AND (node.type IN ('product','tovars'))
ORDER BY node_title ASC
и в форматере поля я тоже нод лоад к сожалению не нашел.
А вот когда строится форма с кнопкой, то там нод лоад выполняется поскольку функции theme_uc_product_add_to_cart(); необходим для построения формы объект node, НО если мы включаем модуль UC_Cart_Link, и заменяем кнопку на ссылку нод лоад не выполняется поскольку для линки достаточно просто nid а уж сделать из нее кнопку я думаю особого труда не составит.
Теперь по поводу дублирования кода из node.tpl.php для тизера что как вы выразились не есть хорошо. Расскажите мне что мешает Вам как программисту написать свою theme функцию которая будет принимать определенные параметы и генерить из них нужный html??
На выходе имеем 1 функцию которую вызываем и на node.tpl.php и на шаблоне филдового вьюса (профит).
Дело в том, что у меня там кэширование не отключается (это ж не рабочий модуль, а так, для проверки). Вообще, тоже интересно, могу проверить на втором хостинге (к it-patrol доступа по FTP уже нет, хотя сайт еще живой).
Ну и код модуля.
vvc.module:
define('VVC_NODES_PER_PAGE', 10);
define('VVC_MSG_NO_DATA', 'No data to display!');
/**
* Implementation of hook_menu().
*/
function vvc_menu() {
$items['products-list'] = array (
'title' => 'Products list',
'page callback' => 'vvc_page_products_list',
'access arguments' => array ('access content'),
'menu_name' => 'primary-links',
);
return $items;
}
function vvc_page_products_list() {
$context = vvc_get_current_context();
// Запрос на выборку опубликованных нод типа Продукт + попытка сразу получить эти ноды из кэша:
$h_query = pager_query("SELECT n.nid, c.data
FROM {node} n
LEFT JOIN {cache_vvc_nodes} c ON n.nid = c.nid AND c.context = %d
WHERE n.type = 'product' AND n.status = 1
ORDER BY n.sticky DESC, n.created DESC",
VVC_NODES_PER_PAGE, 0, NULL,
$context);
$output = '';
$are_nodes = FALSE;
while ($row = db_fetch_array($h_query)) {
// Эта нода есть в кэше:
if (isset($row['data'])) {
$output .= $row['data'];
}
// Этой ноды нет в кэше. Рендерим эту ноду + добавляем ее в кэш:
else {
$node_output = node_view(node_load($row['nid']), TRUE);
$output .= $node_output;
db_query("INSERT INTO {cache_vvc_nodes} (`nid`, `context`, `data`)
VALUES (%d, %d, '%s')", $row['nid'], $context, $node_output);
}
$are_nodes = TRUE;
}
return $are_nodes ? ($output . theme('pager', NULL, VVC_NODES_PER_PAGE)) : t(VVC_MSG_NO_DATA);
}
/**
* Implementation of hook_nodeapi().
*/
function vvc_nodeapi($node, $op) {
// Удаляем из кэша все записи для этой ноды:
switch ($op) {
case 'delete':
case 'insert':
case 'update':
db_query("DELETE FROM {cache_vvc_nodes} WHERE nid = %d", $node->nid);
}
}
/**
* Implementation of hook_flush_caches().
*/
function vvc_flush_caches() {
return array ('cache_vvc_nodes');
}
/**
* Возвращает текущий контекст (для разных контекстов ноды могут иметь различный вид, например, из-за прав юзеров)
*/
function vvc_get_current_context() {
global $user;
// Не будем усложнять
return $user->uid ? 1 : 0;
}
vvc.install:
/**
* Implementation of hook_install().
*/
function vvc_install() {
drupal_install_schema('vvc');
}
/**
* Implementation of hook_uninstall().
*/
function vvc_uninstall() {
drupal_uninstall_schema('vvc');
}
/**
* Implementation of hook_enable().
*/
function vvc_enable() {
// Очищаем весь кэш:
db_query("DELETE FROM {cache_vvc_nodes}");
}
/**
* Implementation of hook_schema().
*/
function vvc_schema() {
$schema['cache_vvc_nodes'] = array (
'fields' => array (
'id' => array (
'type' => 'serial',
'unsigned' => TRUE,
'not null' => TRUE),
'nid' => array (
'type' => 'int',
'unsigned' => TRUE,
'not null' => TRUE),
'context' => array (
'type' => 'int',
'unsigned' => TRUE,
'not null' => TRUE,
'default' => 0),
'data' => array(
'type' => 'text',
'not null' => TRUE,
'size' => 'medium'),
),
'primary key' => array ('id'),
'indexes' => array (
'nid' => array ('nid'),
'context' => array ('context'),
),
);
return $schema;
}
vvc.info:
description = Test - Views vs Custom code.
core = 6.x
version = "6.x-1.0"
По хорошему, в схеме нужно было бы еще сделать unique key по полям nid и context, но здесь это неактуально
Филдовую проверял только с timebased-кэшированием, отличия от "нодовой" естественно нет. Дело в том, что я с самого начала ориентировался на то, что буду использовать views с каким-либо кэшированием. Проверю и это на днях.
node_load() - вообще-то, не единственный тормоз, есть еще node_view(). Поэтому лучше, на мой взгляд, написать нормальное кэширование к views или например display-plugin.
Если мне нужны тизеры нод, варианты следующие (timebased-кэширование не используем, т.к. в реальности оно мало кому подходит):
1) Использовать "нодовую" view. Без кэширования и каких-либо дописываний.
2) Использовать "филдовую" view. Без кэширования и с дописываниями на уровне темизации, как вы и описали.
3) Использовать view например со своим кэшированием. Поскольку есть кэширование, разницы уже нет - нодовую view использовать или филдовую. Поэтому естественно выбираем первый вариант.
Сравниваем варианты 2 и 3 - и там, и там нужно дописывать свое, но вариант 3 явно будет лучше в плане производительности и перспективности. Итого остаются варианты 1 и 3. Хотя, по трудоемкости реализации кэширование конечно будет сложнее.
Если нужна, например, таблица, тут проще - филдовая view без кэширования, либо она же со своим кэшированием.
Нет, это своя вьюха. Где вызывается node_load точно уже не помню, по-моему, все-таки в каком-то форматтере из Уберкарта. Я просто вставил echo в node_load, так и обнаружил, что она вызывается.Да, там действительно есть кнопка добавления в корзину, может именно это влияет, не знаю. Делать из ссылки кнопку - на мой взгляд, это слишком криво, уж лучше ядро Друпала патчить, чем такой фигней заниматься
Вообще, вот тестовый сайт на it-patrol: http://views-or-not-views.atlant.vps-private.net
Добавил результаты филдовой view (перекрестных запросов, правда, не делал
). glu2006: конечно, производительность лучше, чем у нодовой view (почти в 2 раза), но хуже, чем с кэшированием. Так что остаюсь при своем мнении: если нужны именно тизеры нод, лучше сразу написать кэш, чем подгонять внешний вид строк под вид тизеров.
Чтобы сравнивать с филдовой вьюхой, надо и свой модуль допиливать. Вьюс вызывает хуки и шаблоны, для каждого поля - свою функцию темизации, что во-первых, увеличит расход памяти у своего модуля, а во вторых сожрёт много времени на его написание. Вот тут вьюс и начинает выигрывать, т.к. вывод тизеров обычно не требуется, а поля - постоянно.
А если будем сравнивать без кэширования - так сразу и не скажешь, что быстрее. Но мне, честно говоря, не сильно интересно это проверять
Я лучше займусь допиливанием views.
Не факт, это уже кому что надо. Мне, например, сейчас как раз нужны тизеры.Доступ по ФТП отрублен потому что я в отпуске, отдыхаю малость, но если кто хочет, выделю отдельную площадку
Конечно кому как, но мне уже наверное год как не требовались анонсы. Да и неудобно с ними - никакой гибкости.
с анонсами проще
поставил и забыл
А вот, вывод полями этих же анонсов, поставил, помучился с темизацией
Кстати, еще раз обновил цифры (добавил "свой модуль без кэширования", сделал более читабельно).
Вспоминается юзер, который с пеной у рта доказывал, что у него IQ то ли 180 то ли 200+. Хоть убейте не помню, где ента нода - удалили что ли?
Ага, "поставил". Настроил один список, настроил внешний вид тизера. Пошёл настраивать другой список - опа, а там ссылки не нужны или автора надо вывести или... Будешь шаблоны каждый раз корячить?
Всё с точностью до наоборот. Вот допустим нужно мне три дисплея с новостями: Страничный (фото, заголовок, дата, раздел, тизер, автор), Блочный1 (заголовок, фото, дата тизер), блочный2 (заголовок).
Views+views_semantic+css - и никаких шаблонов, всё делается быстро и аккуратно. А если грамотно подойти к именованию css-классов, то внешний вид списков будет меняться просто измением css-класса в настройках. Причём сильно меняться.
views_semantic не знаю такого зверя
Semantic Views
Какая прелесть!
Как верстальщик,я ненавидел вьюс за то что он выводит немеряное количество левых дивов, которые нужно переопределять шаблонами. Перешел на нодовый вьюс.
Когда дошло дело до производительности, с помощью drupal for Firebug увидел что для каждого тизера вьюсы вызывается по три функции, и среди них node_load(). Для каждого тизера свой набор запросов к базе с выбором полей. Тогда я думал что это врпнципе вьюса так устроена, а оказалось что только для "нодной вьюсы". Короче я рад.
Посему у меня вопрос, как-бы это сделать более очевидным для начинающих друпалеров? А то ведь делают на нодных вьюсах а потом пишут на хабре что мол, г.. ваш друпал. У меня на осознание этого ушло 5 месяцев изучения друпала. Понятно что может я не самый умный из всех кто когда-либо начинал изучать друпал, но все равно такие вещи нужно делать более очевидными в доках я не знаю, или прямо в админке вьюса писать "при включении Row style:материал" вьюс работает дольше, и жрет больше ресурсов".
спасибо за семантик
и почему, эту семантику по дефолту не запихнули
Девиз друпала : Все Нужно Допиливать
У Дриса российских корней нет случаем?
Вы как хотите, ребята, а я с Друпала сваливаю окончательно, нечего с ним больше делать...
Ну вот и правильно. Удачи в написании своих крутых решений, а мы уж как нибудь постараемся остаться с друплом.
Ты не поверишь!
Правда до этой надписи ещё добраться надо. Когда-то она была на виду...
Ну наконец-то ты созрел.
Вот, кстати, самый главный аргумент в пользу использования views: даже если бы он был в 10 раз медленнее, чем есть, всё равно надо было бы говорить что он лучший, иначе так и будут плодиться специалисты, думающие, что они пишут быстрый и компактный код.
(( почему, ну почему я этот модуль пропустил(
спасибо за модуль.
нет, нет, неееееет!!!! останься о свет друпал комъюнити! Спаси нас от тьмы незнания!
понедельник начался замечательно
синкора прощай, мы не будем скучать
http://www.youtube.com/watch?v=t3G1vl5UAxU
ха ха)
Да пребудет с тобой Сила, юный падаван!
Синкора, не уходи, я все прощу.
Кто же нас будет веселить нелепыми рассуждениями о производительности ?
Рекомендую Kohana как простой, эффективный фреймворк с быстрым циклом разработки.
Или Yii если хочется супер-производительности (или хочется к ней стремиться), но здесь придется заплатить большую цену за изучение и за разработку каждого приложения. Короче порог вхождения у Yii существенно выше, и я думаю что он оправдан не для одиночек, а для компаний начиная от 10 человек.
petrovnn, не подскажешь(если в курсе), а Symphony по сравнению с тобой указанными как по сложности изучения?
(узнал просто что в моем городе есть одна фирма где на симфони работают)
Я думаю он в пивную сваливает, а не на другой движок.
Написал небольшой обзор основных фреймворков, т.к. на протяжении полугода плотно изучал эту тему: http://drupal.ru/node/52387
Если где ошибся - поправьте кто в теме.
Материал основывается на анализе доступной в сети информации; небольшого опыта работы с несколькими фреймворками и «своих ощущениях».
Если ты считаешь, что так для тебя и твоих проектов лучше - делай. Могу подсказать еще, что в CSS в последней строке в скобках можно не ставить ; - тоже сократит размер CSS
Избыточность наименований есть, но она не критична и скорее необходима.
Для меня лично servis-block несет гораздо меньше информации (да еще скорее я бы ее вообще к БЛОКУ бы отнес, а не строке вьюс), чем "views-row views-row-3 views-row-odd" - причем, views-row и views-row-odd использую постоянно.
"views-field-field-servis-img-fid" против "servis-img" - в первом случае точно понятно, что это отображение отностся к вьюс, а не ноде. Иногда это надо, иногда нет, но...
для меня действительно лучше, удобнее и грамотнее
Вообщем, считаю что именно это место не является проблемным в Друпал, хотя есть знакомые верстальщики, которые приходили в ужас от количества блоков в Друпале
О сколько раз твердили миру...
Ну не нравится вам дефолт, ну переопределите шаблон вьюхи и будет вам счастье, что из мухи слона делать. По поводу производительности вьюсов, споров уже был вагон, Но как показывает практика "миллионы мух не могут ошибаться" если вьюсы говно, то почему он самый популярный модуль друпала?
7 кб! какое несчастье!
kolias23
А теперь посчитайте, сколько вы выиграете после сжатия в gzip. Надеюсь, вам знакома эта технология ? Это первое, что вы должны включать, вместо оптимизации количества тегов, кавычек и прочей чепухи.
Измените ник на К.О. - будет круче.
RxB, если без флуда.
ЧПУ на проект,где потенциально будет несколько тысяч страниц.
Имеет ли смысл? D7 + обычный pathauto.
Если судить по Drupal.ru и Drupal.org, то скорее нет, чем да.
Или компромисс, статьи на ЧПУ, а топики форума нет.
Хотя на LiveStreet на 1 сайте типа мини-соц. сети ЧПУ стояли,
но там пока юзеров ок. 200.
несколько тысяч страниц это ничто для mysql
Несколько тысяч страниц это для WP проблема
Ни верю! Кульный сайт ITC.UA себя на Вердпресс перевел и у них усе файно!
фигней страдаете какой то (это те, кому лишние дивы мешают)
О контенте думайте, о юзабилити, о пользователях.
RxB, спасибо за ответ.
P.S.
Valeratal, по поводу юзабилити. Ваш hr-portal.ru. У меня в FF 9.0.1 на Linux в подвале появляется явно лишний горизонтальный скроллер.
странно, в вин не вижу. Но, тем не менее, я сейчас делаю новую тему - субтему из AT. Думаю скролл пропадет