1 ноября 2010 в 13:21
Добрый день.
В общем у меня вопрос общего характера. Озаботился я что довольно несложный сайт загружается довольно долго (от одной до двух секунд). Прошёлся профайлером (xdebug) и немного опечалился. Обычная страница делает 311 sql-запросов. Это очень много. Очень.
Выяснилось что большинство запросов (171 штука) происходит от функции drupal_lookup_path. Посмотрел её. Ещё больше опечалился. Ребята на каждый запрос к этой функции делают sql-запрос, вместо того чтобы при первом обращении скачать всю таблицу альясов и потом работать уже с ней в памяти. Или хотябы прикрутить несколько стратегий, например если кол-во памяти ограничено, а кол-во альясов велико. Прийдётся переписывать.
Вопрос простой - это нормально что в ядре друпала такой говнокод?
Комментарии
311 - это совсем ничего. Много, когда за 1000
Щас хай подымут, солировать будет RxB
Немного это когда не больше 20-30 запросов. Ну максимум 100, если много хитрого функционала, где одним запросом на операцию не обойтись.
При хайлоаде такой сайт умрет. Можно конечно кешировать результаты запросов (например через memcached), но координально это ситуации не меняет.
Без Синкоры не смогу
Уже несколько раз обсуждалась эта проблема на этом сайте, выкладывались патчи, писались модули, применяющие разные стратегии, где-то на этом сайте они выложены, но так к общему знаменателю и не пришли кажется. Вот такая простая стратегия вытаскивания всех алиасов скопом работает хорошо, когда их немного, были варианты вытаскивать ограниченное число алиасов, наиболее часто востребованных в текущее время, и т.д. Но у каждого по разному как-то требования выходили.
Нет, просто хост будет явно не за 10 баксов.
Друпал - это не говнокод, просто вы платите за модульность производительностью
20 - 30 запросов - это анриал, забудьте
Если так волнует количество запросов - пишите/заказывайте самопись под свои нужды
Нет, поймите правильно, я осознаю что железо дешевле программиста, и понятно что всем не угодишь.
Можно конечно захреначить для сайта с посещаемостью 10к кластер со всеми причандалами (обратный прокси, распределенная бд, итд). Но иногда бывает проще переписать вот такую вот функцию и сидеть припеваючи на старом железе.
Просто мне кажется в данном случае разработчик выбрал неверную стратегию.
Чёрт, опять непонятные слова, где заканчивается Low-Load и начинается High-Load?
Тяжелейший сайт с 100 000 просмотров, на пятом друпале, с друпальным форумом и прочими плюшками, прекрасно живёт на железяке за 100 баксов
это была ирония
Кстате к слову, на дев-сервере, где я сайт профилировал это 300 запросов заняли в общей сложности 41 мс (35 мс на запрос + 6 мс на получение). Ибо запросы простые, бд кешируется и везде стоят здоровые индексы.
Предложенное вами решение очень узкое - на сайты с 5 страничками. Если бы "ребята" пользовались вашей логикой, то Друпал бы никогда не стал столь популярной и мощной системой.
Например, в том проекте, что я делаю сейчас - в таблице urlalias более 38000 записей, и после запуска будет гораздо больше. Надеюсь, никому не надо пояснять, что было бы, если бы таблица альясов читалась бы в память?
Батенька, прочитайте следующее предложение. Мощный и популярный вы наш.
Плюс ничего бы не было, если бы железо позволяло.
1. Да на хрена нужны разные стратегии, которые еще неизвестно, когда применять, если можно действовать простым способом, который во всех ситуациях работает с отличной производительсностью (простые запросы и индексы)? Простое лучше сложного. Постигайте Дао.
2. Это же какое нужно железо? Между прочим, нужно будет сначала 40к альясов передать в ПХП, а потом ПХП должен будет производить по ним поиск(!).
1. Те 300 sql запросов, даже простых и для хорошо индексированных страниц по вашему это нормально?
2. Переделать 40к альясов в PHP это проще чем сделать 40к sql-запросов.
Плюс поиск по таблице можно довольно быстро делать если использовать таблицы ссылок или деревья.
1. Лучше 300 sql запросов, которые выбирают 300 записей из таблицы, чем 1 запрос, который выбирает 40к записей из таблицы. ГОРАЗДО ЛУЧШЕ. Производительность этих 300 запросов будет O(log(n)), где n - количество записей в таблице. Производительность 1 запроса будет O(n). Первый способ гораздо более стабильно и предсказуемо ведет себя при любом количестве записей в таблице альясов.
2. 40к sql запросов - это, если у вас на странице 40к ссылок - а такое бывает достаточно редко, не так ли?
А бинарное дерево уже есть - это индекс таблицы urlalias в sql.
Ну если свое железо то ставите runkit и вперед оптимизировать.
Вот что страдать, когда можно открыть блокнот и хакнуть функцию?
После правки ядра люди не умирают загадочной смертью.
Напишите простенький кэш для функции, заодно мозги потренируете, и может, окажется действительно лучше для вашего проекта.
Даже хакать не надо. Можно клонировать модуль path. Это в голову не приходило? Плюс есть custom_url_rewrite_inbound - пишите свою обработку путей.
Прошу прощения что не собираюсь ни с кем сраться.
Несколько замечаний по делу.
Во первых, кеш алиасов уже в ядре семерки.
Во вторых, в Pressflow есть модуль свой модуль для кеша алиасов.
В третьих, есть модуль, который инициировал ваш покорный слуга: http://drupal.ru/node/19837 посмотрите там в комментах последнюю версию.
Как то так.
pathcache
7-ка нравится все больше
...but is probably only useful if the caching backend has been replaced with memcache.
Смысл от этого модуля? Столько же запросов, только в другую таблицу.
Можно и модуль написать, но сама функция drupal_lookup_path() зашита в path.inc, поэтому её хакинг уменьшит нагрузку не только для алиасов.
Все решения, связанные с кешированием путей, основываются на хакинке path.inc.
Ну дык господа перфекционисты, оптимизирующие запросы, уже давно должны были поставить себе memory based cache. Иначе какие же они оптимизаторы тогда ?
На memcache свет клином не сошелся, есть еще APC, Redis, и т.д. См. модули Cacherouter и аналоги.
Везде одно и то же. Ну и что решил делать? Хостингом выкрутишься? Меня тут недавно убеждали что хостинг для несложного сайта на друпале за 100 рублей можно взять ....
В самом Вашем утверждении уже содержится объяснение.
Действительно, хостинг для ОДНОГО САЙТА можно взять за 100 руб.
Если говорить о шаред хостингах, то увеличение цены хостинга не даст вам лучшее железо.
Внимание! Запомните, а лучше запишите.
Железо останется прежним.
Просто вам дадут возможность сделать два, три, четыре и т.д. сайтов.
Конечно, если речь идет об одном сайте, но на +10000 уников в сутки, то тут вообще про шаред хостинги говорить не стоит.
Далеко идти даже не надо. HandlerSocket plugin для MySQL как говорят работает еще быстрее чем все вышеперечисленное. Для php есть клиент (написан на самом php).
Это ты его собирался бенчмарчить?
Про бенчмаркинг не помню. Сейчас пытаюсь пилить для него модуль под ноду.
Уже накатали для него php-wrapper? Можно ссылку?
http://github.com/tz-lom/HSPHP
Этот враппер я сам не трогал, ничего сказать не могу.