Добрый день.
Столкнулся с проблемой скорости загрузки страниц на каталогах подарков http://begift[dot]ru/ и http://begift[dot]com[dot]ua/ На сайте каждый товар имеет ряд параметров, которые его характеризуют. Параметры, в свою очередь, разбиты по категориям. Например, товар: цветы имеют параметры «Праздник» – 8 Марта, 14 Февраля… и «Кому подарить»: Маме, Жене, Девушке и т.д. Пользователь может свободно комбинировать параметры, на основе которых ему показываются подходящие товары. Пытаюсь оптимизировать данную страницу, поскольку время генерации составляет неприличные 10-15 сек: http://tools[dot]pingdom[dot]com/fpt/#!/[dot][dot][dot]god-iz-igrushek/
Подбор товара осуществляется алгоритмом: параметры внутри категории объединяются оператором ИЛИ, сами категории – оператором И. Страница, кроме основного списка, показывает также количество подарков, которое будет получено путем комбинирования уже выбранных и дополнительных параметров. Этот расчет также происходит по тому же алгоритму. Таким образом, мы имеем около 30 таких выборок на каждую загрузку страницы. В большинстве случаев используем подготовленные запросы, но для таких страниц запрос полностью генерируется в php коде вместе с параметрами. Он довольно объемный и плохо оптимизируется с самой базой. Я уже реализовал кэширование (сохраняя результаты всех вычислений для каждой страницы) на стороне сервера. Так как стоимость товара и его наличие обновляется, то этот кэш нужно обновлять раз в 1-2 дня. Страниц около 3000, если кэшировать каждую каждый день, то только на кэширование уйдет 10 часов.
Хочу провести сравнительные тесты разных альтернативных алгоритмов. Возможно, у кого-то есть опыт в таких задачах. Буду благодарен за совет.
1. Sheehave - 13 Мая, 2015 - 15:54:04 - перейти к сообщению
2. Мелкий - 13 Мая, 2015 - 16:02:35 - перейти к сообщению
Sheehave пишет:
Таким образом, мы имеем около 30 таких выборок на каждую загрузку страницы.
Из чего это вытекает?
Покажите схему БД и код. Если цифры на главной имеют отношение к количеству предложений - то городить несколько уровней кэшей ради пустяковых пары тысяч товаров смешно.
3. DeepVarvar - 13 Мая, 2015 - 16:09:58 - перейти к сообщению
Мало инфы. Ты там что, лайками ищешь чтоли? Для каждого параметра заведи айдишник. Ищи по названию в таблице параметров и джойнь все товары через таблицу связи:
properties
id, title
products
id, ..., ..., ...
products_properties
property_id, product_id
Тип такого:
properties
id, title
products
id, ..., ..., ...
products_properties
property_id, product_id
Тип такого:
CODE (SQL):
скопировать код в буфер обмена
скопировать код в буфер обмена
- SELECT p.*
- FROM properties pts
- INNER JOIN products_properties ppts
- ON ppts.property_id = pts.id
- INNER JOIN products p
- ON p.id = ppts.product_id
- WHERE pts.title LIKE ...
Sheehave пишет:
Это сраные копейки.
Страниц около 3000