24 июля 2009 в 10:21
Собственно вопрос к знатокам друпала, а суть вопроса в следующем:
Имеем - машина Core2Duo 2.6 + 2гига оперативки + mysql 5.0.26 + php 5.2.5 + eaccelerator + чистый друпал 6.13 + словарь таксономии.
Словарь таксономии - трехуровневый иерархический список населенных пунктов РФ - около 155 тысяч записей.
Так вот собственно при загрузке страницы которая связана с данным словарем и соответственно на которой выбирается необходимый термин время загрузки превышает 40 сек. плюс к тому же потребление памяти зашкаливает за 300мБ...
Такие цифры при работе на реальном сервере естественно не допустимы.
Так вот собственно вопрос - можно ли каким то способом сократить время загрузки и потребление памяти?
Может быть имеются варианты?
Комментарии
на странице добавлении ноды весь словарь грузится чтоли? без hierarchical_select ?
hierarchical_select ставил. Что с ним, что без него суть не меняется.
Судя по посту да :).
Я бы разбивал на словарь на составляющие
1 таблица регионы/области
2 таблица города/села
3 таблица адрес в городе
все таблицы увязать по ID т.е.
город -> ID региона,
адрес -> ID региона, ID города.
Похожий пример смотреть тут:
http://www.rest-ua.com/apartments
или тут http://www.busybrains.com нажать на кнопку купить и далее из корзины на шаге оформления покупки вкладка SCHOOL там около 150.000 Английских школ для выбора.
Разбить словарь не сложно, но как потом увязать эти словари, причем так, что бы они подгружались в зависимости от выбора предыдущего уровня?
Для этого и существуют activeselect и hierarhical select.
Но в Вашем случае я бы не пользовался стандартной таксономией. А сделал бы свой модулек который занимается именно категоризацией регионов и далее в глубь. Есть для этого если я не ошибаюсь модулек для CCK http://drupal.org/project/cck_address но правда он под 5-ку, попробуйте портировать его на 6-ю ветку.
На busybrains кстати самопис и там каждая школа это нода, т.е. без товаров уже 150000 нод.
и работает же.
cck_adress работает с данными беря их из файла и сохраняет в собственной таблице. Соответственно материалы привязать к терминам таксономии затем нельзя. К тому же это не решает задачу - все равно при таком количестве данных происходят тормоза.
а active_select и hierarchical_select подгружают полностью словарь при выборе каждого следующего уровня... так что тоже не вариант...
Вы заметили тормоза на сайтах что я Вам давал?
хотя найдутся и противники (не исключено).
Я написал что оптимальный вариант писать свой модуль. А если использовать таксономию то надо напильником поработать основательно (обратить внимание на индексы в БД в пересекающихся таблицах). Эти сайты работают на основе модуля http://drupal.org/project/category таксономи курит
Тормозов там конечно особых нет, но опять же, category подменяя, модуль таксономии, все равно пишет данные в таблицы этого модуля, да и к тому же практически все модули расчитаны на работу с taxonomy, а не с category, поэтому применять category в моем случае бессмысленно, т.к. в этом случае придется переписывать практически каждый модуль, в том числе и модули ядра...
Сейчас пока переписываю hs_content_taxonomy, что бы загружал в массивы не весь словарь, а лишь по выбранным уровням. т.е. если к примеру у словаря три уровня, то загружается только верхний уровень, во втором уровне загружаются только "дети" выбранного пункта 1 уровня, и в третьем уровне "дети" выбранного пункта 2 уровня.
Правда пока туго идет, т.к. логика модуля очень запутана... автор наверное с большого будуна его писал.
Модуль категори оборачивает модуль таксономии в свою специальную обертку благодаря которой все остальные модули работают с категори думая что работают с таксономией
исключение в 5-ке составлял вьюс, там приходилось немного извращаться. Под 6-ку я пока ничего сказать не могу поскольку не приходилось еще юзать.
Хочу поспорить...
Модуль обертка для таксономии скрывает модуль таксономии, синхронизирует в БД таблицы модуля таксономии - vocabulary, term_data и term_hierarchy, из которых остальные модули и черпают информацию...
Если Вы обратили внимание, то при инсталляции модуля категори и включении обертки для таксономи заменяет стандартные файлы taxonomy.module и taxonomy.info на свои с таким же названием и похожим набором функций, а старые переименовывает + перетягивает модуль категории из блока ядро к себе в категори. Поэтому говорить о том что модули пользуют стандарные функции таксономии не правильно, да действиетльно данные остальными модулями черпаются именно из таблиц таксономии но функциями несколько иными по содержанию (конечно-же не все).
ЗЫ. Я бы все-таки писал свой модуль.
Я бы свободным вводом тегов делал.
Так ведь если дать пользователям вводить свои термины - они там такого могут понаписать, что потом устанешь словари править... Тем более что есть полная база населенных пунктов...