Комментарии 19
«слоистая навигация». гм, отличное выражение, буду теперь использовать, когда надо будет озаботить коллег :)
Многослойная красивее звучит. А вообще такая штука называется фасеточный поиск (faceted search)
Спасибо за подсказку. К сожалению, правильно называть никто не учил, поэтому и выходим из ситуации как получится. А вообще, за мою практику вариантов было много — и выборки, и фильтры поиска… сейчас так и называем ее — лэеред навигейшн.
Везде по-разному называют. Например, в движке Prestashop это называется Layered Navigation. Так что автор поста перевел правильно.
А как там с быстродействием? Она всё такая же прожорливая?
А как давно Вы с ней общались? От версии к версии движок становится быстрее. Так что если Вы работали с ней крайне давно — будете удивлены быстродействием.
Сейчас у меня в проекте почти 50 000 товаров, около 200 категорий. Сервер на CentOS 5, 1GHz, 1GB RAM, использую xCache и memcached. Планирую увеличить ресурсы вдвое, т.к. на данный момент уже не хватает.
А посещаемость какая?
Около 1000 уников в сутки. По правде говоря, немного жалею о выборе, т.к. индексирование стандартными средствами уже сейчас не происходит, завершается ошибкой 500. Пришлось написать shell скрипт, который производит индексирование.
У знакомого на PrestaShop база в 3 000 000 товаров, магазин лежит на средних параметров виртуальном хостинге. Пока в разработке, но выдерживать без нагрузки 3 млн. позиций — уже неплохой результат.
У знакомого на PrestaShop база в 3 000 000 товаров, магазин лежит на средних параметров виртуальном хостинге. Пока в разработке, но выдерживать без нагрузки 3 млн. позиций — уже неплохой результат.
НЛО прилетело и опубликовало эту надпись здесь
Есть какие то конкретно на примете? Т.к. в данный момент склоняюсь к идее что для высоконагруженных проектов необходимо искать альтернативное решение. (Особенно утвердился в этой мысли после того, как на одном буржуйском сайте по предоставлению хостинга под Magento самый дешевый тариф был снабжен 16 Gb оперативной памяти...)
Для высоконагруженных приходится разрабатывать свои. Я из PHP укладываюсь в 200МБ ОЗУ при возможности обработать 300 запрос/секунду долговременно (~25 миллионов в сутки), возможно кратковременная нагрузка в 1000 запросах, но не дольше, чем на 5 секунд. Для работы достаточно сервера с 2ГБ ОЗУ при том, что 500МБ это я рассчитываю на дисковый кэш.
Но как я понял, альтернативное двигло было найдено? Сколько хоть запросов держит и каких ресурсов требует?
Но как я понял, альтернативное двигло было найдено? Сколько хоть запросов держит и каких ресурсов требует?
А есть уверенность, что наращивание железо исправит ситуацию? Поддержу вопрос от Artime насчет посещаемости. И уже из чистого любопытства — не рассматривался ли вариант смены движка?
В этом релизе появился новый алгоритм PLN (Price Layered Navigation).
К существующим двум:
1. Manual (в котором явно задается шаг, и максимальное число интервалов)
2. Automatic (Equalize price ranges), который автоматически разбивал множество на интервалы, но выбирал при этом шаг равный степени 10. И останавливался, когда число интервалов становилось большим либо равным двум.
добавился
3. Automatic (Equalize product count), в котором используя статистические данные по выборке строится распределение. В данном случае интервалы будут содержать приблизительно одинаковое число продуктов.
И этот новый метод действительно работает медленней, чем предыдущий (2) на выборках до 100к продуктов. В первую очередь из-за накладных расходов в связи с дополнительными запросами к базе данных.
Если используется Solr данная разница едва ли заметна.
К существующим двум:
1. Manual (в котором явно задается шаг, и максимальное число интервалов)
2. Automatic (Equalize price ranges), который автоматически разбивал множество на интервалы, но выбирал при этом шаг равный степени 10. И останавливался, когда число интервалов становилось большим либо равным двум.
добавился
3. Automatic (Equalize product count), в котором используя статистические данные по выборке строится распределение. В данном случае интервалы будут содержать приблизительно одинаковое число продуктов.
И этот новый метод действительно работает медленней, чем предыдущий (2) на выборках до 100к продуктов. В первую очередь из-за накладных расходов в связи с дополнительными запросами к базе данных.
Если используется Solr данная разница едва ли заметна.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Вышла Magento 1.7.0.0