Форум PHP

Здравствуйте сообщники.

Имеется сферический скрипт с категориями и товарами в этих категориях.
При листинге товаров в категориях есть кнопки-ссылки сортировки "по цене" (asc, desc) и, разумеется, постраничная навигация, т.к. выводится, к примеру, по 10 товаров на страницу.

Массив с данными 10 товаров кэшируется в файлы, для каждой из страницы свой с такими названиями:

cat555-page1.cache cat555-page2.cache

И потом массивы с данными из этих файлов успешно парсятся средствами php и выводится на страницу без запросов в БД.

Пока дело не доходит до сортировки.

Да, я могу пересортировать полученный массив 10 товаров из одного файла и показать его на странице по возрастанию цены.
Но ведь "выборка" будет "нерепрезентативна" - товары будут отсортированы только в своем массиве "одной страницы".
А не во всей категории.

Что я делаю не так?

Логично, что при выборе сортировке нужно обновлять кэш.
Схема может быть такая: в кэш отправляются только данные с сортировкой по умолчанию. Когда пользователь выбирает другую сортировку, то не кэшировать.
Второй вариант: обновлять кэш страницы только для этого пользователя, используя уникальный идентификатор сессии либо передавать уникальное значение в куках, соответственно именуя файлы кэша этими уникальными id.

делайте больше кэшей.

cat555-page1-asc.cache
cat555-page1-desc.cache

и т.д

Создавать бОльшее количество кэш-фалов не вариант, т.к. не хватит места ни на hdd, ни в памяти:

- сортировка не только по цене происходит, но и по дате (новизне), по отзывам и т.п.
- категорий 2000 шт.
- да и фильтр населенного пункта присутствует наряду с другими фильтрами

То есть мне нужно для одной категории сделать большое количество кэш-файлов:

кол-во городов * кол-во категорий * кол-во страниц в каждой категории * кол-во сортировок * 2 (desc и asc)

Остается вариант не кэшировать эти выборки и это меня сильно печалит.

А что же тогда кэшировать? Только страницы с товарами?

Либо действительно кэшировать хоть только дефолтную выдачу категории, а уже при сортировке доставать напрямую из БД.

какой хостинг и какая посещаемость на сайте?

VPS: камень 2.40 GHz, ddr: 512Mb.
Посещаемость 10k-11k хостов.
Категорий около 2300 шт с общим (плавающим) количеством товаров около 30k-40k.

На отладочном сервере (без посетителей) sql-запросы на такие выборки отрабатывают в дельте 0.005 - 0.05 с.
А вот что будет на продакшене я и пытаюсь предугадать.

> Создавать бОльшее количество кэш-фалов не вариант
Так вы ж не будете сами создавать кеши для всех возможных вариантов.
Вы получаете запрос. Проверяете наличие кеша именно для этого запроса. Если есть - отдаете и обновляете время последнего использования, если нет - создаете страницу, сохраняете кеш и отдаете.
Потом, можно по крону, удаляете кеши, которые не использовались, скажем, 5 суток.
В любом случае у вас кеши не будут равномерно использоваться. Будут, например, редкие какие-то, которые раз в месяц будут созданы и благополучно удалятся, а будут какие-то популярные, которые будут использоваться постоянно.

Да что-то ссыкотно мне запускать кэширование, которое в пике может создать файлов на

6000 городов * 2000 категорий * 5 (среднее количество страниц в категории) * 3 (сортируем по дате, цене, новизне) * 2 (desc и asc) * 30 kb (средний размер кэш-файла) = 10.800.000.000 kb

Удаляется кэш у меня только при внесении изменении в данные (в категории или в товары).
То-есть просрочки, как таковой, нет.

может стОит кэшировать только самые популярные страницы категорий/товаров? или, если проще, то наверное все-таки имеет смысл кэшировать только основные, т.е то что открывается без фильтров и постраничной навигации. как ни крути, они будут самыми популярными и основная нагрузка будет исходить оттуда.
и есть ли смысл это всё запихивать в массив? наверное всю страницу кэшировать было бы эффективнее с точки зрения расходования ресурсов. разве что только кэш был бы тяжелее

> То-есть просрочки, как таковой, нет.
Так сделайте. Что мешает?

> = 10.800.000.000 kb
Да ни в жисть такого не будет, если у кеша будет срок жизни.
Вам для этого понадобится не 10k-11k хостов, а 100М-200М хостов.
И уж в этом случае вы упретесь в другие барьеры, нежели место на диске.
И ничто не мещает вам следить за статистикой, вести рейтинги популярности запросов и в случае чрезмерного объема кеша, перейти, например, на кеширование только тех запросов, которые бывают скажем 3 раза в день и более.

> psychomc (16.06.2013 в 19:43)
> и есть ли смысл это всё запихивать в массив? наверное всю страницу кэшировать было бы
> эффективнее с точки зрения расходования ресурсов. разве что только кэш был бы тяжелее
Вот я этот момент вообще упустил.... Конечно нужно кешировать готовые страницы. Иначе грош цена такому кешу.

> > То-есть просрочки, как таковой, нет.
> Так сделайте. Что мешает?

Да, уже спрототипировал - по cron будет срабатывать скрипт и удалять слишком старые файлы кэша, что бы он не разрастался.


> может стОит кэшировать только самые популярные страницы категорий/товаров? или, если проще, > то наверное все-таки имеет смысл кэшировать только основные, т.е то что открывается без
> фильтров и постраничной навигации. как ни крути, они будут самыми популярными и основная
> нагрузка будет исходить оттуда.

Да, я пришел именно к такому варианту.


> и есть ли смысл это всё запихивать в массив? наверное всю страницу кэшировать было бы
> эффективнее с точки зрения расходования ресурсов. разве что только кэш был бы тяжелее

Это не возможно, т.к. помимо всего прочего существуют пользовательские настройки вывода списка товаров (списком, галереей и т.п.) и для этого мы берем массив с чистыми данными и раскладываем в нужном пользователю шаблоне.
А иначе мне придется кэшировать еще и разные варианты скомпилированных страниц :)

>> = 10.800.000.000 kb
>Да ни в жисть такого не будет, если у кеша будет срок жизни.
>Вам для этого понадобится не 10k-11k хостов, а 100М-200М хостов.
>И уж в этом случае вы упретесь в другие барьеры, нежели место на диске.
>И ничто не мещает вам следить за статистикой, вести рейтинги популярности запросов и в случае чрезмерного объема кеша, перейти, например, на кеширование только тех запросов, которые бывают скажем 3 раза в день и более.

Ну я же привел это чисто гипотетически.

> Ну я же привел это чисто гипотетически.
Зачем же проектировать реальное приложение, под гипотетическую нагрузку?
Это все равно, что купить самолет в кредит с обоснованием: а вдруг когда разбогатею, а у меня нет самолета - это ж не солидно!
=)

>Это не возможно, т.к. помимо всего прочего существуют пользовательские настройки вывода списка товаров (списком, галереей и т.п.) и для этого мы берем массив с чистыми данными и раскладываем в нужном пользователю шаблоне.
А иначе мне придется кэшировать еще и разные варианты скомпилированных страниц :)

на самом деле еще как возможно. как правило, в шаблонизаторах есть возможность (не)кэшировать отдельные части шаблона