Скорость работы Drupal

Главные вкладки

Аватар пользователя radev radev 16 августа 2006 в 17:25

Dries провел сравнение Drupal 4.7.3 с Joomla 1.0.10 - в итоге вышло что Joomla быстрее только при отключенном кэшировании страниц (что касается быстродействия для зарегистрированных пользоваталей, так как для них кэш страниц не работает.)

В своем сообщении Dries призывает рассмотреть все возможные варианты улучшения быстродействия, а также обещает рассмотреть присланный патчи как можно скорее (ASAP).

В комментарии на странице сравнения Robert Douglass написал что Drupal 4.8 должен стать намного быстрее, если будут рассмотрены некоторые патчи.

Источник в drupal-devel

Комментарии

Аватар пользователя B.X B.X 20 августа 2006 в 4:35

если честно, то определённые улучшения присутствуют, но говорить об "ощущении невооружённым взглядом" я бы торопиться не стал... есть ещё проблемы...
да, при использовании gzip - странички загружаются быстрее, да, -скорость возросла в кешировании фильтров, и вообще всё выглядит значительно лучше, чем раньше... но вместе с тем, иногда (довольно часто) присутствуют непонятные "зависания" при редактировании, добавлении материалов и даже при переключении между страницами...


проблема "перевода на лету" оставаясь одной из "фич" Друпала, вместе с тем, показывает, насколько всё плохо... конечно, можно говорить, что это "не так уж и плохо" и "совсем не мешает", но очевидное отрицать глупо...
да, при удалении почти всех модулей, расширяющих функциональность движка, Друпал довольно неплох, но как он выглядит при нагрузках? прямо скажем, не идеально... если не сказать больше, даже Друпал на официальном сайте, который имеет неплохой выделенный сервер и то притормаживает, о чём это говорит?
да, как сказал Аксель (приводя цитату какого-то известного человека) "за функциональность приходиться платить", но мне интересно, как тогда обеспечивают схожую функциональность (не во всём, конечно, подобных Друпалу - нет) другие системы? при довольно-таки неплохих показателях по скорости?


в общем, есть куда развиваться, как мне кажется... я никогда не понимал, зачем вставлять целые предложения и текст в модули? ведь скорость обработки таких модулей растёт, а значит будут присутствовать и замедления... а например, в случае, с модулем locale, так при отображении будут ещё и постоянные коннекты к базе данных (ведь надо заменять текст)... до сих нельзя похвастаться полноценным переводом под Друпал, хотя вроде как всё для этого сделано... а другие системы схожего уровня щеголяют полноценными русскими версиями движков и это не является для них проблемой...
как недостаток считаю то, что Друпал просто обязан хранить два варианта перевода в себе, в случае если сайт не на английском языке... и тд. и тп...
я не буду говорить о кодировках, но они тоже всё усложняют, точнее усложняет простое отсутствие их поддержки и замена на универсализм utf-8, универсализм - это не всегда хорошо... так же как и явная специализация...
какие выводы можно сделать? есть куда расти и что изменять... слава высшим силам, Друпал - это ГПЛ? а значит - всё в наших руках...

Аватар пользователя Natalie Natalie 20 августа 2006 в 4:48

Ради, интереса, а какие движки со схожей функциональностью быстрее Друпала? Мамбо вроде если и быстрее, то ненамного.
---
---
All content management systems suck, Drupal just happens to suck less. -- Boris Mann at DrupalCON Amsterdam, August 2005.

Аватар пользователя B.X B.X 20 августа 2006 в 4:57

коммерческие, некоторые, которые пробовал... Битрикс, например... там страница на несколько десятков килобайт, а всё так быстро переключается, добавляется и тд... движки форумов (плюс портал, плюс много хаков расширяющих)... и работают без тормозов, при гораздо больших нагрузках, работает нормально поиск и тд.

Аватар пользователя Natalie Natalie 20 августа 2006 в 6:18

нуу, коммерческие - это немножко другой зверь. А что с open source?
---
---
All content management systems suck, Drupal just happens to suck less. -- Boris Mann at DrupalCON Amsterdam, August 2005.

Аватар пользователя Dan Dan 20 августа 2006 в 11:27

B.X, мне кажется ты валишь всё в одну кучу.
Если бы переводы хранились не БД, а обрабатывались gettext (или "прошивались" в модули или ещё как...), думаешь у Drupal`а был бы полный русский перевод? Это проблема маленького русскоязычного сообщества. И решать её другими способами надо. Наверняка ситуацию изменят инсталяторы, мастера и т.д., плюс к этому, мне просто интересно, когда же в Drupal`е появится _красивая_ тема в стандартной поставке? Smile А до тех пор он (или она? - Drupal) будет "на лицо ужасные, добрые внутри" Smile
Все говорят, что внутри Drupal устроен великолепно, вот только жаль, что пользователь не понимает это при первой установке (встречают-то по одёжке...)

Про UTF.
"но они тоже всё усложняют, точнее усложняет простое отсутствие их поддержки и замена на универсализм utf-8"
Правильно подметил - кодировок (во мн.числе) больше нет! Нет кодировок - нет проблем, связанных с ними. А если проблемы есть - меняйте хостера.

"универсализм - это не всегда хорошо…"
Это не универсализм, это стандарт, стремящийся к универсальности. Он не идеален но одночначно лучше, чем зоопарк кодировок.

Аватар пользователя radev radev 20 августа 2006 в 15:07

Одно из главных преимуществ Drupal - в удобстве написания кода. Мне доводилось писать код для gallery2(расширение функционала, сейчас стоит на farmboystockyard.com), phpBB, FUDforum (в основном, изменения во внешнем виде) - с точки зрения это ад.

У gallery чересчур формализован процесс работы с базой - если делать все "правильно" - для простого сохранения в базу пишется объект для хранения свойств и helper class.

У FUDforum очень часто приходится править исходники форума - низкая расширяемость.

В Drupal мы платим за расширяемость, которой нет у других проектов. Я более чем уверен, если из кода Drupal удалить все комментарии - сайт заработает быстрее, так как у многих нет APC cache для PHP - код заново парсится при каждом некэшированном запросе.

Аватар пользователя dyp@drupal.org dyp@drupal.org 20 августа 2006 в 16:10

т.е. если в готовом сайте который не будет меняться и расширяться с точки зрения кода, убираем из всех модулей комментарии, неисползуемые функции, убираем локализацию и делаем перевод прямо в модулях, то сайт будет просто летать.

Аватар пользователя Natalie Natalie 20 августа 2006 в 19:16

Dries сам сказал, что нужна новая тема. Но явно не в следующем релизе Sad
---
---
All content management systems suck, Drupal just happens to suck less. -- Boris Mann at DrupalCON Amsterdam, August 2005.

Аватар пользователя B.X B.X 21 августа 2006 в 3:23

Quote:
[b]Если бы переводы хранились не БД(...)умаешь у Drupal`а был бы полный русский перевод? Это проблема маленького русскоязычного сообщества[/b]

у Друпала "НЕ маленькое" сообщество , особенно если судить по сайту drupal.ru, и дело не в том, что никто не хочет переводить... просто сам процесс перевода сложен и трудоёмок... а всё из-за чего? посмотрите сколько в Друпале различных справок, помощи, комментариев, одним словом "воды", которую тоже нужно переводить... и это при наличии форумов, полноценного сайта полного документации и различных сайтов поддержки... зачем всё это было внедрять в движок? какой в этом смысл? одно дело разработка и настройка и другое дело - использование... если прибавить сюда gettext (понятный тоже разработчикам только) и хранение данных в БД, что тоже не уменьшает понимание, кому захочется возиться? а учитывая то, сколько надо переводить, боюсь Друпал и к следующей версии будет испытывать те же самые проблемы...


именно то, что в Друпале так просто и удобно программировать (а также вставлять комментарии и текст в сами модули) привело к тому, что в некоторых модулях текста больше, чем программного кода (известный пример BBCode)... зачем это? как говорится "благими намерениями"... и как от этого теперь избавиться?
в других системах человек трижды подумает, прежде чем вставлять хоть одно лишнее слово, а в Друпал всё просто t'( и пиши что хочешь... это расслабляет и ведёт к ненужному злоупотреблению...


Quote:
[b]В Drupal мы платим за расширяемость[/b]

я согласен платить, но не так много... это уже не нормально, когда попав на тот или иной сайт и заметив, что он притормаживает я начинаю думать "это не Друпал случайно?"... в ближайщее время, лично я собираюсь вставлять русский перевод прямо в модули для себя и буду использовать как можно меньше текста (в конце концов, во многих местах он просто лишний, что такое таксономия я уже знаю и так и если что, смогу прочитать в другом месте, если забуду)... использовать locale я не намерен, да пусть мне скажут, что я не прав и "так неправильно", но иначе не получается...
разработчики не предложили и не предложат "по-видимому" никакой альтернативы... ждать ещё десять лет? увольте...

Quote:
[b]Это не универсализм, это стандарт, стремящийся к универсальности. Он не идеален но одночначно лучше, чем зоопарк кодировок.[/b]

чем лучше? где свобода выбора? где поиск, который не работает на "других кодировках"? разве это нормально? я не буду спорить, да и незачем, каждый пусть решает сам, что ему по душе...

Quote:
[b] коммерческие - это немножко другой зверь[/b]

в чём разница? почему коммерческие могут работать быстрее, а Друпал не может? открытый код, улучшать его есть возможность, какие проблемы? почему не могут найти лучших решений? и если эти решения есть, то почему они не используются?
форумов, которые быстрее работают уже стало много PhpBB, например и его младшие собратья... раньше был IPB, но стал коммерческим... проблем с отображением информации там не было никогда, так же как и с кодировками и прочим...

Аватар пользователя kiev1 kiev1 22 августа 2006 в 10:44

поиск работает в русской кодировке нормально и даже удалось заставить по шаблонам искать, но то что поиск не морфологический - это да, надо что-то врое dpsearch ставить

Аватар пользователя B.X B.X 23 августа 2006 в 17:54

а где вы видели возражения против utf-8? наоборот, есть возражения против других кодировок и зачем - непонятно... не так уж много там непонятного, чтобы их было не добавить... наоборот, всё специально сделано, чтобы с другими кодировками нельзя было нормально работать...

Аватар пользователя Nickolyan Nickolyan 25 августа 2006 в 12:31

По сайту естественно шастают поисковики и пару раз в день нагрузка на процессор хостера выше разрешенных в 2, то и в 4 раза. Хостер пока не ругается, но можно ли както уменьшить количество одновременных запросов от поисковиков?
--
С приветом, Nickolyan

Аватар пользователя dyp@drupal.org dyp@drupal.org 25 августа 2006 в 12:52

Только если попросить их не больше не приходить прописав в robots.txt что то типа "Вон отседа и чтоб я тебя больше не видел!". Smile
Теоретически наверное можно через тот-же robots. Например написать скрипт который будет анализировать UserAgent на предмет поисковиков, и если пришел яндекс то прописывать для остальных disallow.

Аватар пользователя Nickolyan Nickolyan 25 августа 2006 в 13:00

Я думаю стоит хотя-бы им запретить ходить туда, где генерятся доступ запрещен или требуется авторизация... Только вот сообразить не могу что прописывать и как. Ну я попробую про robots.txt яндекс попытать...
--
С приветом, Nickolyan

Аватар пользователя rgb rgb 29 августа 2006 в 10:57

Народ,

про возможности и недостатки Дрюпал я в основном согласен. У меня сейчас только один вопрос к людям, которым так не нравится факт хранения переводов в БД. Можно ли узнать, откуда у вас такая святая вера в то, что Дрюпал за каждым словом лезет в базу!? Это утверждение встречаю уже не первый раз и не на первом форуме. Ну почему вы не потратите 5 минут, на то, что бы скачать и установить devel.module и не посмотреть "а как оно работает" на самом деле?

А происходит там всего-навсего 1 (один!) запрос к кэшу, откуда вылавливаются все пары для перевода и далее они в массиве хранятся и доступ к ним осужествялется без всякого дёргания БД. Всё очень просто.

Разумеется я говорю о "нормальном" режиме ф-ционирования (этот кэш обновляется не очень часто, когда админ что-то правит на сайте).

Конечно, памяти требуется для этого и всё такое, но это уже другой вопрос.

2All: Извините, просто надоело видеть в форумах высказывания, которые делаются просто так, не подумав, не проверив, не разобравшись...

Аватар пользователя B.X B.X 29 августа 2006 в 13:21

интересно, а если кэш не работает, тогда что? тогда тормоза или постоянные задержки, да и зачем вообще было переводы пихать в базу (когда можно было просто заменять всё в файлах, в тех же po-файлах, если уж на то пошло)? совсем тупых здесь нет и мы понимаем, что при наличие кэша - всё нормально, но если он отключен, тогда что? тогда он таки лезет за каждым словом, да ещё в кэш постоянно что-то добавляет (который вроде бы отключен)...

Аватар пользователя dyp@drupal.org dyp@drupal.org 29 августа 2006 в 18:05

У меня кэш отключен, но перевод он как я понял все равно из кэша берет. Т.е. как я понял если вы отключили кэш это не значит, что он не работает.

Аватар пользователя Dan Dan 31 августа 2006 в 1:50

B.X "... да и зачем вообще было переводы пихать в базу (когда можно было просто заменять всё в файлах, в тех же po-файлах, если уж на то пошло)?"

Ты что, поклонник Windows? Smile У неё для каждого языка своё ядро - с нужным языком, вот веселуха!*
Разработчики Drupal поступили правильно - в стиле unix-way. То, что работает на сайте (ядро и модули) должно быть точно такое же, что и у разработчика - это мы сейчас и имеем: перевод и темы отдельно. Если изменения вносятся в модуль - всё!, за его работоспособность разработчик, по сути, ответственность не несёт, ибо файлы изменены.

Есть два пути (имхо) хранить/получать перевод - через gettext ("переводит" php) или БД. Чем БД хуже gettext можешь сказать?

* (для последних версий это уже не так).

Аватар пользователя kiev1 kiev1 31 августа 2006 в 18:33

> Ты что, поклонник Windows?

а я вот линуксом гентой пользуюсь - рекомендую всем - система портов лучше фри

Аватар пользователя B.X B.X 1 сентября 2006 в 6:22

"Чем БД хуже gettext можешь сказать?"
оно не хуже, неправильная постановка вопроса... это также, как спросить, - "чем база данных хуже файловой системы"? Она не хуже файловой системы, но у них разное предназначение.
Что происходит, если мы храним переводы в базе данных? Происходит множественное обращение к ней. Зачем? PHP (который бы только ставил замену одного на другое) тратил бы на это меньше ресурсов, потому что база данных и так в Друпале нагружена сверх меры. Заменять одни слова на другие через базу данных ресурсоёмко и нецелесообразно.
И для чего это вообще? Только ради того, чтобы можно было переводить онлайн? Хм... бред, учитывая количество материала для перевода, которое не собирается уменьшаться.

Аватар пользователя rgb rgb 1 сентября 2006 в 16:11

Про отключенный кэш: опять же можно глянуть в код или почитать, что разработчики по этому поводу пишут... С кэшем такая штука: отключая кэш, Вы, действительно, не выключаете его, для каких-то внутренних нужд (в частности для локализации) он продолжает использоваться. Т.е. отключается кэш страниц и блоков, но не весь кэш.

B.X wrote:
Что происходит, если мы храним переводы в базе данных? Происходит множественное обращение к ней.

Я всё же осмелюсь утверждать, что не происходит этого постоянно. Только при обновлении кэша (когда меняем или добавляем строки перевода).

Аватар пользователя coyotle coyotle 1 сентября 2006 в 16:15

еще из моих исследований, очень много запросов (чуть ли не четверть или больше) генерит drupal_lookup_path - это нечто из модуля path...

Аватар пользователя B.X B.X 1 сентября 2006 в 16:16

[b]"Я всё же осмелюсь утверждать, что не происходит этого постоянно."[/b]
Один раз при изменении, каждый раз при изменении кэша, не много ли это? когда кол-во соединений с базой всегда ограничено? я считаю что много, хотя, конечно, понимаю, что есть и другие мнения... но locale всё равно требует много ресурсов, это видно, достаточно поставить модуль devel...
[b]"Т.е. отключается кэш страниц и блоков, но не весь кэш."[/b]
блоки тоже постоянно кэшируются...
[b]"отключая кэш, Вы, действительно, не выключаете его, для каких-то внутренних нужд (в частности для локализации) он продолжает использоваться."[/b]
как это соотнести с первой фразой о том, что кэш не используется постоянно, если для модуля locale это-таки постоянно и происходит? короче, грустно всё это, грустно... надеюсь хоть что-то разработчики сделают, главное, хорошо бы иметь выбор, делать простенький малопотребляющий ресурсы сайтик или мегапортал, пока этого выбора нет и каждый сайт на Друпале - это мегапортал, который жрёт ресурсы...

Аватар пользователя rgb rgb 1 сентября 2006 в 17:04

B.X wrote:
Один раз при изменении, каждый раз при изменении кэша, не много ли это? когда кол-во соединений с базой всегда ограничено?

Боюсь, что не понимаю Вас сейчас: поясните, что значит "Один раз при изменении, каждый раз при изменении кэша"? И причем тут кол-во соединений к БД?

B.X wrote:
блоки тоже постоянно кэшируются…

Ага! Значит Вы всё же заглядывали в код! Lol Ок! Тут я был не прав...

B.X wrote:
как это соотнести с первой фразой о том, что кэш не используется постоянно

!? Я не говорил, что кэш не используется постоянно... Я лишь утверждал (выше ещё), что в штатном режиме эксплуатации, для целей локализации используется один (1) запрос к БД (на страницу), а именно - к таблице кэша. И оттуда достаётся сразу весь набор "слово или фраза"=>"перевод" и в дальнейшем, при формировании страницы за переводом в БД никто не суётся. Вот это я утверждал и утверждаю. Wink

Я, наверное, Вас запутал словом "постоянно". В контексте работы сайта и вкл./выкл. кэша, "постоянно" - следует понимать как "не зависимо от того, включено ли кэширование для страниц". А в контексте отрисовки страницы - под "постоянно" я понимаю "доставать из базы перевод для каждой фразы отдельно, не одним запросом".

Вот так.

Аватар пользователя dyp@drupal.org dyp@drupal.org 1 сентября 2006 в 16:45

Quote:
еще из моих исследований, очень много запросов (чуть ли не четверть или больше) генерит drupal_lookup_path - это нечто из модуля path

drupal_lookup_path работает при вызове l(бла бла бла)

Аватар пользователя B.X B.X 1 сентября 2006 в 17:10

ладно, не будем спорить, спор этот бесполезен, потому что никаких конкретных шагов не будет, так смысл? просто я считаю, что хранить неизменяемые (в принципе) данные в БД - это нелогично, так же как нецелесообразно хранение информации помощи (хелпов различных) в самой CMS...
да и посмотрите на нагрузку модуля locale тоже...

Аватар пользователя rgb rgb 1 сентября 2006 в 17:30

Ок. Прекращаем спорить. Smile

B.X wrote:
неизменяемые (в принципе) данные в БД - это нелогично

Согласен с Вами!

B.X wrote:
так же как нецелесообразно хранение информации помощи (хелпов различных) в самой CMS

Ну тут есть свои плюсы - есть шанс, что находясь рядом с кодом, который реализует описаные фичи, справка будет с большей вероятностью актуальной... Хотя, это, конечно не гарантия.

B.X wrote:
да и посмотрите на нагрузку модуля locale тоже…

Хорошо, как смогу, я гляну что там к чему. Для 4.6 я ковырялся в этом всём, и могу сказать, что для моего сайта, нагрузка, которую даёт locale, была не самой большой (по сравнению с другими местами в коде).

Про 4.7 пока не готов ничего сказать.

Всё-всё... заканчиваем спор. Smile

Аватар пользователя marazmus marazmus 1 сентября 2006 в 19:10

Вот-вот, самое-самое то, натюрлих!

Для сайтов с не сильно/часто изменяемым контентом это в самый раз, кажися мне.

Аватар пользователя B.X B.X 1 сентября 2006 в 18:59

хм... очень интересно, надо будет потестить и попробовать...
файловый кэш будет всяко быстрее БД-шного...

Аватар пользователя Natalie Natalie 1 сентября 2006 в 19:13

Вроде в 5.0 должны быть улучшения в области и кэша. Надо бы потестировать.
---
---
All content management systems suck, Drupal just happens to suck less. -- Boris Mann at DrupalCON Amsterdam, August 2005.

Аватар пользователя dyp@drupal.org dyp@drupal.org 1 сентября 2006 в 19:45

drupal_lookup_path не зависит от path и path_auto, как оказалась. Он запрашивает алиасы. Чтобы таких запросов не было нужно очистить таблицу url_alias

Аватар пользователя B.X B.X 1 сентября 2006 в 19:47

[b]"http://drupal.org/project/fastpath_fscache
добрые люди делают модуль файлового кэша. т.е. храниться он будет на диске, а не в базе. Вери бета.
У меня к стати из 253 запросов 90 обращение к кэшу."[/b]
жаль, не работает пока, бета, что поделать... будем ждать релизов...

Аватар пользователя Dan Dan 2 сентября 2006 в 11:16

B.X: "Она не хуже файловой системы, но у них разное предназначение."
Я понимаю, что у БД и у gettext разное предназначение - не ребёнок Smile Однако в данном контексте я имел ввиду "чем хранение перевода в БД хуже чем в файлах .po".

Теперь поговорим о том, как это всё работает.
Вариант БД: При трансляции модуля PHP вызывает функцию t, которая, через ф-ю locale обращается к БД и выдёргивает оттуда перевод (с учётом кэширования).
Вариант PHP-gettext: При обработке ф-и, аналогичной t (не помню название), PHP вызывает gettext; тот "лезет" за переводом в mo-файл (это, если не ошибаюсь, компилированный po-файл). Кэширование, насколько я знаю, не производится.

На мой взгляд БД больше оптимизирована под такие запросы и скорость получения подобной информации у неё выше. Спорить не буду, ибо здесь нужны точные цифры по скорости для сравнения, просто у меня создалось впечатление, что ты не совсем понимаешь работу всей цепочки, иначе не говорил бы "...PHP (который бы только ставил замену одного на другое)".

B.X: "И для чего это вообще?"
В частности для независимости. Пример: на мастерхосте PHP не поддерживает gettext, из-за этого, когда я ставил gallery, пришлось собирать свой PHP.

Аватар пользователя B.X B.X 2 сентября 2006 в 23:00

хех, ну давайте, давайте всё запихнём в БД... она распухнет, мы будем каждый день производить оптимизацию, будем увеличивать запросы к базе... а может вообще и файлы не нужны?
кэширование производится в php gettext точно также, если функции повторяются и если, конечно на хостинге есть для этого соответствующее программное обеспечение...

Аватар пользователя Dan Dan 3 сентября 2006 в 0:35

"хех, ну давайте, давайте всё запихнём в БД"
Это единственное конструктивное возражение против хранения переводов в БД?

"мы будем каждый день производить оптимизацию"
Мы каждый день добавляем переводы?

"а может вообще и файлы не нужны?"
Какие файлы?

"кэширование производится в php gettext точно также, если функции повторяются и если, конечно на хостинге есть для этого соответствующее программное обеспечение…"
Если. А в БД, к тому же, есть ещё оптимизация...

Аватар пользователя rgb rgb 3 сентября 2006 в 1:33

Кстати, о птичках... Ни кто иной как axel сделал для Дрюпала 4.5 (если не ошибаюсь) модуль, который как раз и брал перевод через gettext.

2axel: Что Вы думает по этому поводу (gettext vs. DB)? И почему модуль не получил дальнейшего развития?

Аватар пользователя jason32 jason32 7 сентября 2006 в 13:40

Quote:
Теперь поговорим о том, как это всё работает.
Вариант БД: При трансляции модуля PHP вызывает функцию t, которая, через ф-ю locale обращается к БД и выдёргивает оттуда перевод (с учётом кэширования).
Вариант PHP-gettext: При обработке ф-и, аналогичной t (не помню название), PHP вызывает gettext; тот “лезет” за переводом в mo-файл (это, если не ошибаюсь, компилированный po-файл). Кэширование, насколько я знаю, не производится.
На мой взгляд БД больше оптимизирована под такие запросы и скорость получения подобной информации у неё выше. Спорить не буду, ибо здесь нужны точные цифры по скорости для сравнения, просто у меня создалось впечатление, что ты не совсем понимаешь работу всей цепочки, иначе не говорил бы “…PHP (который бы только ставил замену одного на другое)”.
B.X: “И для чего это вообще?”

Мда , что называется инерция мышления.почему бы не сделать проще, как во всяких левых форумах - include файл перевода вначале( ассоциативный глобальный массив), а функция t() проверяет, есть ли там переведенная строка -если нет - лезет в базу за английской версией - это если приличия блюсти, а если положить - то модно и английский вначале инклюдить - и запросов тогда вообще никаких не будет. А конвертер из .po файла в что-нить такое написать раз плюнуть.Понятно, что это хак, но если искрутиться, то может быть выйдет оформить это как модуль, я думаю.

В настоящее время самый простой и реальный вариант - убрать подзапросы алиасов урлов для каждого нода - сделать один запрос , вытянуть их все в массив и оттуда уже кормиться.Я в своем журнале http://drupal.ru/node/2317#comment-9914 - провел небольшие статистические выкладки - знатоки, прокомментируйте...

Аватар пользователя rgb rgb 7 сентября 2006 в 14:46

Quote:
почему бы не сделать проще, как во всяких левых форумах...

Начнём с того, что Дрюпал - не "левый форум"... Lol

А если серьёзно, то почти так и происходит: вначале из кэша вся таблица переводов выгребается, а потом к ней обращения происходят. Да Вы это уже, наверное, и так прочли...

Quote:
Понятно, что это хак, но если искрутиться, то может быть выйдет оформить это как модуль, я думаю.

Я тут могу, конечно и "пургу гнать" (не проверял просто), но может так оказаться, что инклюд большого файла с PHP-массивом, по времени может быть сопоставим с выборкой этого массива из БД (там же коннект есть, осталось выполнить 1 запрос к кэшу и забрать результат).

Quote:
В настоящее время самый простой и реальный вариант - убрать подзапросы алиасов урлов для каждого нода ...

Ой, какой резкий переход от локализации к урлам Smile Пошёл читать...

Аватар пользователя jason32 jason32 7 сентября 2006 в 15:13

Quote:
Я тут могу, конечно и “пургу гнать” (не проверял просто), но может так оказаться, что инклюд большого файла с PHP-массивом, по времени может быть сопоставим с выборкой этого массива из БД (там же коннект есть, осталось выполнить 1 запрос к кэшу и забрать результат).

Нет, на Include() ресурсов почти не уходит - в этом весь стиль программирования на php - всё инклюдится, скрипт собирается как сборная солянка перед выполнением, нагрузок на сервер никаких

Аватар пользователя rgb rgb 7 сентября 2006 в 17:32

Quote:
Нет, на Include() ресурсов почти не уходит...

Может быть... Пока спорить не буду (действительно, мало у меня информации про это). Замечу только, что инклуд - это как минимум, несколько вызовов ф-ций для работы с файловой системой (проверить наличие файла, права на него и прочее..). Как-нибудь проверю (действительно интересно стало :-)).

Аватар пользователя axel axel 14 сентября 2006 в 22:21

Не забываем, что при работе include всё содержимое файла загребается в память. Разумно делать инклюды только когда они необходимы. А если перевод не на один язык, а на десяток? Забирать все переводы сразу?

--
Axel,
Darcs-репозиторий разработок для Drupal

Аватар пользователя B.X B.X 7 сентября 2006 в 19:34

[b]"Нет, на Include() ресурсов почти не уходит - в этом весь стиль программирования на php - всё инклюдится, скрипт собирается как сборная солянка перед выполнением, нагрузок на сервер никаких"[/b]
плюс если на хостинге установалена програмное обеспечение, которое кэширует выполнение скриптов, то это вообще сказка, в отличие от базы данных...

Аватар пользователя jason32 jason32 8 сентября 2006 в 10:11

Quote:
Может быть… Пока спорить не буду (действительно, мало у меня информации про это). Замечу только, что инклуд - это как минимум, несколько вызовов ф-ций для работы с файловой системой (проверить наличие файла, права на него и прочее..). Как-нибудь проверю (действительно интересно стало

Не совсем понял, про какие вызовы функций идет речь - никакие там права не проверяются( разве что на чтение и то вряд ли), и наличие файла для работы скрипта необязательно - он просто выдает предупреждение и продолжает работать.

Аватар пользователя rgb rgb 8 сентября 2006 в 22:36

Quote:
Не совсем понял, про какие вызовы функций идет речь...

Извините, я не объяснил. Я про вызовы на уровне интерпретатора PHP. Для того, что бы PHP "понял" есть файл или нет, можно его читать или нет и т.п. интерпретатор делает ряд системных вызовов в рамках обработки инструкции include и ей подобных.

Аватар пользователя jason32 jason32 11 сентября 2006 в 9:14

Quote:
Извините, я не объяснил. Я про вызовы на уровне интерпретатора PHP. Для того, что бы PHP “понял” есть файл или нет, можно его читать или нет и т.п. интерпретатор делает ряд системных вызовов в рамках обработки инструкции include и ей подобных.

Знаете , если так копать, то в итоге дойдем до ассемблера и машинных команд.Можно вспомнть, что и Mysql проверяет, есть ли дамп базы( каждая таблица которой занимает 3 файла), их читает, обрабатывает, разжимает и тд и тп. Всё это ерунда - работа с файлами быстрее и самое главное не нагружает базу, у которой и так обычно дофига работы - у меня и так ещё три форума крупных вертятся и ещё Друпал там нагружать будет.

Аватар пользователя rgb rgb 11 сентября 2006 в 17:31

Quote:
Знаете , если так копать, то в итоге дойдем до ассемблера и машинных команд

До сих пор не приходилось в веб-разработке до этого доходить, только при написании дров Wink

Quote:
Можно вспомнть, что и Mysql проверяет, есть ли дамп базы( каждая таблица которой занимает 3 файла), их читает, обрабатывает, разжимает и тд и тп.

Ну mysql-ю легче - у него демон всё время в пямяти висит и читать базы при каждом запросе ему не надо Wink

Quote:
Всё это ерунда - работа с файлами быстрее и самое главное не нагружает базу...

...но нагружает дисковую подсистему.

Вообще говоря, всё это "зависит от" (много от чего зависит).

Хорошо, я готов согласиться с тем, что Вам файлы локализации и вправду ощутимый выигрыш приносят... Smile