19 октября 2010 в 20:20
Началось все с того что во время гугления об оптимизации дру наткнулся на провокационную статью: http://habrahabr.ru/blogs/drupal/53189/
После прочтения статьи возник вопрос - «как-же так мой друпал обвиняют в неродивости»!
Решил разобраться в ситуации и расставить все точки над i. Включил модуль девел чтобы замерить:
- кол-во запросов
- время генерации страницы
- оперативку, которую кушает система на генерацию страницы
И обнаружил (для меня) довольно неожиданный результат. Запросов действительно было много.
- 380 запросов, 28мб, 1.3 сек (главная)
- 200 запросов, 25мб, 0.7 сек (страница одного типа контента)
- 100 запросов, 20мб, 0.4 сек (страница второго типа контента)
Понятно дело что админу сайт выдается без кеширования.
Посему у меня вопрос:
Как узнать сколько запросов и сколько памяти потребляется при выдаче страниц анонимам при стандартном друпаловском кешировании?
Как узнать эти параметры если я включу Boost? Я пытался решить эту задачу с разных сторон, но видимо небольшой опыт использования друпала, или вообще PHP и серверной части этому мешает. Буду очень признателен за рецепт или хотя-бы направления (куда копать), чтобы научиться отслеживать производительность для анонимов.
Еще филосовский вопрос: действительно-ли важно количество запросов, или это просто холивар?
Уверен что функциональный сайт (портал) можно оптимизировать чтобы он очень быстро отдавал содержимое, даже наверное с несколькими десятками запросов. Так важно-ли сколько запросов, или важнее время генерации? А ведь в анти-друпаловской агитации кол-вом запросов аппелируют как "убийственным аргументом", после которого хоть трава ни расти, но друпал все равно - г.
В догонку еще один анти-друпаловский линк: http://habrahabr.ru/blogs/personal/15401/ где человек жалуется опять-же на большое кол-во запросов.
Друпал - сложная система. Сложная как для ньюбов, так она оказывается сложной и для некоторых опытных программеров. Это значит что нужно иметь очень много терпения и упорства для того чтобы выучить эффективные методы разработки и оптимизации. Но значит-ли это что дру - плохая система, или это просто ее специфика? Судя по некоторым отзывам на хабросе возникает ощущение что человек сталкивается с проблемой, и не желая тратить много времени и сил на ее решение приклеивают друпалу ярлык «плохая CMS». В моей практике встретился один опытный прогер, который не сумел разобраться в темизации друпаловских шаблонов, опять-же приклеив соответствующий «ярлык». Люди хотят решение, которое можно и «галочками» настроить, и чтобы масштабировалось хорошо, и чтобы памяти немного жрало, и чтобы модулей было много и качественных и поддержки, чтобы держало большие нагрузки, да чтоб еще и освоить было легко! Но они не понимают что некоторые пункты из этого списка взаимоисключают друг друга!
Хочешь универсальности и модульности, плати... нет, не количеством запросов и не временем загрузки страницы. Плати долгим и упорным изучением правильных методов работы с друпалом. Так и хочется сказать: «Как, вы не любите друпал? Вы просто не умеете его готовить!»
Гугл инвестирует в развитие друпала до полумиллиона долларов с 2007 по 2010 гг.
Автор первой критической статьи у себя в профиле пишет что работает в гугле. При этом показывает явное не уважение к движку и нежелание в нем разбираться. У меня это вызывает крайнюю степень удивления, потому что никто как гугл не вкладывает столько денег в развитие друпала. Последнее вливание гугла - 90 000 $ в апреле 2010г. http://buytaert.net/google-to-invest-90000-usd-in-drupal-again (справа заметки о других, более ранних вливаниях).
Если этот человек действительно работает в гугле - неужели он полностью игнорирует причины такой благосклонности (если не назвать это спонсорством) своей великой компании? Гугл на сегодня является пожалуй самой влиятельной "програмистской" компанией. Имею ввиду что гугловцы всегда делали основной упор на скорости и эффективности любого ПО, которое они разрабатывают от поиса до браузера. Основатели - сильные программеры, почти ученые. Из этого следует и их подход на подбор сотрудников (набирают таких-же как они сами) - "предельно умных". И вот эти люди выбирают из всех веб-платформ и фреймворков именно друпал для того чтобы вложить в него денег. Для чего...??? наверное для того чтобы развивать инет таким образом. Или может они таким образом вылавливают сильных программистов из друпал-сообщества? А может и то и другое сразу?
В общем предела нет моему праведному гневу. Почему люди часто упускают из вида тот факт что на друпале сделать функциональный современный инфо-портал НА ПОРЯДОК выгоднее чем на любом другом фреймворке? Почему как было замечено в комментах к первой статье на стоимость владения не обращают внивания, а вырывают из контекста некие "факты", якобы дискредитирующие друпал как хороший движок? Рассмотреть-бы картину в целом, а?
Комментарии
и че?
Количество запросов - ерунда.
Производительность части известной цепочки производительности "сервер"-"канал связи до пользователя" характеризует время генерации страницы.
Читал в книге по php "Библия пользователя", 2007 год: "Самое большое время занимает создание соединения с БД. После этого по созданному соединению количество запросов не влияет почти."
Возможно так и есть, но почему в таком случае "количеством запросов" аппелируют как чем-то фундаментально важным, и типа если много запросов - то плохо?
Потому что цена даже простого запроса ненулевая (и некоторые шаред хостинги имеют в этом плане ограничения). Естесственно, чем меньше запросов, тем лучше, однако у Друпала большинство запросов простые и используют индексы. Не знаю как там на шаред хостинге, но у меня на выделенном сервере на запросы тратится в среднем только треть (а в случае тяжелых страниц - еще меньше) от общего времени генерации страницы.
Как узнать
при выдаче страниц анонимам при стандартном друпаловском кешировании?
memory_get_usage()
timer_read('page')
поставьте opcode cacher
xxandeadxx, спасибо. То что нужно.
статья на хабре вообще не в тему
Что значит "не в тему"?
Когда говорят что у друпала 500 запросов на страницу юзается это нужно во-первых проверить, во-вторых объяснить почему так. Не сомневаюсь в том что друпал отличная система, просто для меня подобные порядки оказались неожиданными.
Вот Crea написал по-делу - большинство запросо простые, используют индексы. Уже лучше. У xandeadx нашел способ отсечь часть запросов от drupal_lookup_path http://xandeadx.ru/blog/drupal/16 (сейчас почему-то в дауне, но есть в гугло-кеше). Конечно это патчинг ядра (насколько я понял), но если выбирать между связкой pathcache+мемкеш, то xandeadx-кий вариант реализуется на порядок проще.
Про память. Оказывается, у меня грузился массив со всеми полями каждой ноды, используемой на странице, независимо от того тизер это или страница данной ноды. Ошибку помогла осознать установка Firebug for Drupal, где перечислены все загруженные массивы при генерации страницы.
таких тем и на д.ру достаточно
где человек сталкивается с проблемой запросов к бд, оптимизации использования памяти он вешает ярлык плохая cms.
но друпал это всего лишь интструмент для решения определенных задач. и если с его помощью не получается решить какую то задачу, то это проблема выбора инструмента, а не самого друпала.
У меня сейчас по тесту siege сайт на D7 отдается без кеширования с той же скоростью что и сайт на php чистом с минимум запросов к базе. С кешированием в 10 раз быстрее.
Но конечно надо будет судить уже на рабочем в полную проекту.
Хорошо сказано
Проблема с запросами имеет место быть. Всякие там россказни про несущественность и некую "быстроту и простоту" этих запросов очевидно обычные отмазки фанатично настроенных товарисчей.
Кстати, 380 запросов на главной - прекрасный по меркам Друпал результат, 700 и более не хотите ли?
Как с этим бороться? Никак. Хотим модульную конструкцию и универсальность - давимся тем что есть, так как затраты на сокращение этих запросов перекроют возможные выгоды, т.е овчинка выделки не стоит. Хотим построить большой и высокопроизводительный сайт - выкидываем Друпал нах, вбухиваем кучу бабла и пишем двиг под свою задачу с нуля. Это к вопросу, почему ВКонтакте не на Друпале
Дремучее, воинствующее невежество.
Лучшие умы в сообществе оптимизировали эти запросы, чтобы они использовали индексы, минимум джойнов, и выполнялись за миллисекунды. Потом приходит (самый умный) Volocuga и называет это отмазкой.
Важно не количество запросов, а их суммарная сложность с точки зрения движка базы, а с этим у Друпала (говорю за ядро, а не за произвольные модули) все хорошо. Один неоптимизированный запрос стоит тысячи простых.
Ситуация драматизируется персонажами, покупающими хостинг за $5 c жутким оверселлом.
Ну что за бред. Минимум джойнов говорите? А как они этого минимума добились? Правильно вместо того, чтобы написать
t.*,
u.*
FROM
topics t
INNER JOIN users u ON u.uid = t.author_id
Пишем запрос
t.*
FROM
topics t
А потом к каждой строчке вызываем запрос:
u.*
FROM
users u
WHERE
u.uid = $1
Но зато мы от джойнов избавились и запросы все простые, и используют индексы.
Почему при выводе форума количество запросов растет пропорционально количеству постов? Неужели трудно одним махом выбрать все посты?
И почему при генерации простейшей страницы у меня 18 раз выполняется запрос:
SELECT DATA, created, expire, serialized FROM cache_menu WHERE cid = :cidНу Вконтакт слишком специфический сайт для такого движка, а вот examiner.com на drupale 176 место в америке по посещаемости и 548 в мире.
Так что стоит.
Но да, запросов много, поэтому думаю на таких посещаемых сайтах идет ручная оптимизания запросов.
Examiner на MongoDB, впрочем, скорее не от количества запросов, а от количества документов. Поэтому пример не очень удачный.
Пример реально крупного сайта на Друпале с мускулем - Drupal.org
Если кто из критиков Друпала дорос до такой посещаемости - респект и уважуха. Но боюсь, большинству до таких масштабов...