Siegfrid@drupal.org: Комментарии

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

2 декабря 2010 в 16:06

Оговорюсь сразу, что я не спец по оптимизации сложных SQL запросов. но в данном случая я бы ушел от опператора IN и просто попытался бы присоединить таблицу term_node к базовому запросу и дальше фильтронул бы по критерию where, как то как:

2 декабря 2010 в 15:01

насколько я знаю, вот это не очень замечательная вещь, там вроде как MySQL не может использорвать ключи или что то в таком духе:
AND node.nid in (
SELECT term_node.nid
FROM term_node
WHERE tid=%d
)

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

2 декабря 2010 в 13:51

eLSe wrote:
Увы, тут проблема не закрепить сами термины за доменами, а в том, чтобы на странице /taxonomy/term/tid ссылки на материалы шли не на текущий домен, а на тот, за которым закреплен сам материал...
А вообще наш модуль заменял в материале ссылки на термины таксономии ссылками на описания соответствующих услуг (определяя при этом домен, за которым закреплена публикация).

2 декабря 2010 в 11:55

eLSe wrote:
В том что запросы не влияют я уже убедилась. У меня максимальное количество запросов - в материале "Офис", и то они выполняются менее чем за 400мс. А вот время формирования страницы этого материала - ужас! О_О около минуты! Причем только на этом типе материала... Даже не знаю на что грешить. Яндекс-карта или самописный модуль (заменяет ссылки с таксономии на статьи по услугам)? Изначально с ними все летало.

2 декабря 2010 в 10:07

RxB wrote:
2500 просмотров слишком мало чтобы об этом думать.
С твоими цифрами времени генерации самый большой профит получится после использования акселлератора

2 декабря 2010 в 10:01

Softovick wrote:
<a href="mailto:Siegfrid@drupal.org">Siegfrid@drupal.org</a> wrote:
ну и просто м.б. сервак хероватенький, то тут только свалить с него либо на другой, либо от хостера к чертям собачьим!

2 декабря 2010 в 8:46

<a href="mailto:Krotty@drupal.org">Krotty@drupal.org</a>][quote="eLSe" wrote:
255.08 главная, самый сложный вьювс пэйдж - 297.02

2. Не работающий eAcelerator - попробуйте отключить и сравните время генерации

проще с помощью phpinfo() посмотреть, что там с eAcelerator, работает ли он или так, прохлождается...

29 ноября 2010 в 8:14

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

29 ноября 2010 в 8:08

размер - 80 метров.
У меня на ноуте фактически с теми же параметрами развернута тестовая база, на ней бывают некоторые updateдлятся по 200 мс, но это в виде исключения.

29 ноября 2010 в 1:16

3,2 секунды - UPDATE sessions SET uid = 1, cache = 0, hostname = '81.201.17.109', session = 'language|s:2:\"ru\";dblog_overview_filter|a:0:{}views|a:6:{s:11:\"User_images\";a:1:{s:7:\"default\";a:1:{s:11:\"date_filter\";a:3:{s:5:\"value\";N;s:3:\"min\";N;s:3:\"max\";N;}}}s:7:\"Gallery\";a:1:{s:12:\"panel_pane_1\";a:2:{s:5:\"title\";s:0:\"\";s:11:\"date_filter\";a:3:{s:5:\"value\";N;s:3:\"min\";N;s:3:\"max\";N;}}}s:13:\"Advertisement\";a:1:{s:12:\"panel_pane_1\";a:1:{s:11:\"date_filter\";a:3:{s:5:\"value\";N;s:3:\"min\";N;s:3:\"max\";N;}}}s:5:\"Goods\";a:1:{s:12:\"panel_pane_1\";a:1:{s:11:\"

29 ноября 2010 в 1:14

например запрос INSERT INTO accesslog (title, path, url, hostname, uid, sid, timer, timestamp) values('Галереи', 'exibition/gallery', 'http://www.gulvar.ru/zapis-v-dnevnike/kollektivnyi-razum', '81.201.17.109', 1, 'b7b51f641953dfad88f32a8f0097d8f1', 15971, 1290982246) у меня выполнянлся 3,2 секунды... и такое частенько происходит с разными insert/update

5 ноября 2010 в 9:57

Косяк оказался куда глубже - в модуле views где то есть проблема, которая выражается в том, что создается дополнительный join таблицы node с сама самой по полю tnid ( LEFT JOIN node node2 ON node.tnid = node2.tnid надо для синхронизации переводов контента на разные языки). Все бы хорошо, да вот не использую я такую фичу, это видно и по самому запросу.

Временный workaround - закоментить файл translation.views.inc на __translation.views.inc и сбросить кеш.

4 ноября 2010 в 19:20

по ходу дела проблема известная:
http://drupal.org/node/940268
http://drupal.org/node/904038
и т.д. - http://drupal.org/search/apachesolr_multisitesearch/node2.tnid%20views

Так что если у вас появилась проблема с производительностью, то весьма возможно это как раз ваш случай