Yii, EAV, производительность?

Question

[MUTOgen4eg]

Доброй ночи.
Столкнулся с таким вопросом. Есть довольно тяжелая обработка сущностей на сайте на базе Yii.
Кратко опишу суть: есть товары, которые имеют настраиваемые модификации (как, например, телефоны 8Гб и 16Гб, только реально параметры могут быть разные + на один товар может быть несколько взаимосвязанных параметров и количество значений может отличаться).
Сейчас на товарах один вариативный параметр (в среднем у каждого товара есть 5-7 вариаций). Все это реализовано через EAV.
Проблема в том, что производительность не совсем устраивает. 1 страница категории = 17 товарам, что занимает 3,5-3,7 секунд на сервере. Профилировка кода и запросов показывает, что около 2-х секунд уходит на вызов типа (повторяется он 141 раз на одной странице):

$attribute = Attribute::model()->with('options')->findByAttributes(array('name'=>$attr));

Логика подсказывает использовать кэширование, пусть даже кратковременное, но добавление ->cache(120) ничего не дает. Боюсь чем дальше это пойдет (я имею ввиду несколько вариативных параметров на товар), тем будет хуже.
С какой стороны стоит зайти для решения этого вопроса?

Comments

[Сергей Протько]

Из вашего описания ничего особо не понятно. Что нужно знать:

Количество запросов для страницы (только те что нужны для каталога) и примеры оных.
Используются ли индексы для поиска?
Опишите примерную архитектуру базы, если классическая eav модель, то откуда берутся эти запросы вида

$attribute = Attribute::model()->with('options')->findByAttributes(array('name'=>$attr));

мол, зачем выбирать опции атрибута по одному?

[Сергей Протько]

И было бы неплохо привести пример кода из контроллера, где идет выборка, и пример кода где идет обход полученных моделей.

Answer 1

[Сергей Протько]

вы используете вот эту штуку? Просто выкиньте и перепишите с inner/left join-нами для выборок.

Comments

[MUTOgen4eg]

Да, используется эта вещь. Рад бы выкинуть но на нем базируется большая часть логики, как backend так и frontend =\ Тут выше я писал, что разработка ведется не с нуля, а на базе готовой платформы

[_ _]

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

[MUTOgen4eg]

В общем-то думаю так и придется делать "по месту".

[Сергей Протько]

Это еще что, я сейчас один такой проектик доставшийся мне на поддержку "по месту" на симфони перевожу (точнее на его компоненты, для более удобной миграции в будущем).

[MUTOgen4eg]

:) осознание того, что у меня все не так плохо, вселяет оптимизм

Answer 2

[Masterme]

запросы в цикле делаете что ли?

Comments

[MUTOgen4eg]

Неявно получается так. Устроено таким образом, что __get проверяет наличие приставки eav_ при обращении к свойству и если таковое имеется то вступает в дело eav behavior (через его методы вытаскивается id значения параметра), ну а далее уже этот самый запрос, чтобы отобразить само значение.

[Сергей Протько]

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

[MUTOgen4eg]

Делает он много чего полезного, но тут я думаю проблема в самой логике использования. Вытаскивать один и тот же атрибут с его значениями (опциями) 141 раз смысла мало, поэтому вопрос как лучше подойти к решению такой проблемы. Не вытаскивать в этом месте - не вариант, т.к. повалится все остальное, работающее на магическом __get, поэтому я и подумал о кэшировании

[Masterme]

@MUTOgen4eg сделайте всю выборку одним SQL-запросом

[MUTOgen4eg]

@Masterme да, спасибо, буду переписывать плохие участки именно так

Answer 3

[_ _]

При работе с БД не должно быть ничего неявного - вы должны от и до понимать, как работает тот или вызов ActiveRecord.
Я разрабатывал магазин на Yii, товары с вариативными параметрами, параметры в отдельной таблице, связь "много ко многим" - все нормально бегало.

Comments

[MUTOgen4eg]

К сожалению или счастью, но разработка ведется не с нуля. Используется готовая базовая платформа интернет-магазина, поэтому приходится работать с тем, что есть

[_ _]

По вопросу:
Если вы вынуждены вызывать Attribute::model()->with('options'), значит у вас что-то не в порядке с проектированием моделей и связей между ними.
У вас должна быть модель, отображающая промежуточную таблица many-to-many (если я правильно понял, это у вас options), из модели товара к ней должна быть связь has_many.
В самой модели options у вас должна быть связь belongs_to к модели atribute
Выбирая товары вы говорите goods->with('options','options.attribute')->findAll($criteria)
Вы этом случае такой вызов вторым запросом к БД "жадно" вытащит все значения вариативных параметров к выбранным товарам, и соотв. аттрибуты.
На все про все уйдет два запроса.