Со скидков в 50% готов заказать 10 штук. Домены будут свои, свежие. Жду в ЛС.
Дам старт )
6000 .
Старт на первый.
Универсальность НИКОГДА не давала скорости работы движков ;)
Вынести языковые данные в файлы - APC/eAccelerator поможет в работе.
100к уников в сутки в инет-магазине и нет средств на поддержку ресурса? Ладно, в сторону подобное... По технической части: я не говорил что не нужен кеш, я сказал, что надо кешировать только то, что требуется, а не все подряд.
В реализации, а не в настройках ;). Если хранить вместо данных еще и разметку (а я еще видел как и js+css был в закешированных данных) - вытеснение данных будет идти намного быстрее, верно? 2-4 гига - это мелочь, на сегодняшний день. И поверьте, проще и дешевле поставить 32 гига памяти, чем наглухо оптимизировать скрипт и потом его поддерживать.
Думаю, что если есть десяток проектов средней популярности - можно найти деньги и поставить то железо, которое обеспечит комфортную работу не только базе, но и разработчику. А то получается, что хотите выделить по 200-400 метров памяти на каждый проект и требовать адекватной работы от него. Конечно, такое возможно, но маловероятно.
Кстати, при 100к униках и таких сложных требованиях к запросам, есть проще вариант для кеширования: сохранять отдаваемую страницу целиком в файловый кеш на относительно не большое время (1-60 сек) и следующим посетителям отдавать напрямую через apache/nginx, минуя php. Плюсы: минимальное потребление ресурсов, быстрая работа, минимум конфигурации (при использовании nginx - он сам все это может делать, даже код менять не надо).
P.S.: как-то Вы путаетесь в параметрах... то один проект на 100к и кеш для него продумывается, то десяток средних и думаем о расходе ресурсов под них. Разные задачи - разные решения.
Нормальная (и единственно правильная) практика: при изменении данных в хранилище - удалить кеш, связанный с этими данными. В Вашем случае - удалить кеш для запросов данного типа. Это будет удобно сделать, если каждый тип кеша скидывать в свою папку.
Да ладно? ))) Я, пока что, знаю только один проект, на котором не используются джойны. Но знаю кучу других, на которых джойны используются в полную силу. Есть и цифры: 250-300к уников в сутки на 1-м сервере базы данных. С кучей джойнов.
Тут все зависит от кривизны рук, если честно. Вообще, это даже хорошо - в кеше только те данные, которые нужны. Да и заполнить 2-4 гига памяти данными из базы - довольно проблематично, если честно. Посчитайте сами: если все данные из базы на 1 товар весят 2-3 кб (а это ОЧЕНЬ МНОГО), то для заполнения 2-х гигов памяти надо 700-1000 ПОПУЛЯРНЫХ товаров, т.е. таких, в которые заходят много разных людей и часто. Реальна ситуация? Думаю нет... А если да - то значит не проблема найти 16-64 гига памяти, т.к. магазин уже ОЧЕНЬ популярный ;).
Во-первых, кто Вам сказал, что джоины непременно заставят базу тормозить? Правильное использование ключей спасет в 99.99% случаев. Будь хоть сотня джойнов, при не большом размере таблиц и правильно настроенных индексах - не почувствуете.
Во-вторых, основный принцип кеширования - сохранить часто запрашиваемую, но редко изменяемую информацию. Чаще всего, в кеше сохраняют не фрегменты страниц (хотя и это бывает оправдано), а результаты запросов - меньше весят, проще проверить валидность кеша.
В-третьих, пагинация, сортировки, фильтры и пр. - это отдельные кеши, никак не связанные между собой. Ведь даже по умолчанию все это используется, часто скрыто. Поэтому, решение простое: смотрим все параметры, генерируем ключ и по нему сохраняем (в дальнейшем получаем) данные. Например:
$cache_key = "catalog_{$sort}_{$desc}_{$filter}_{$page}";
Изменился любой параметр - получаем новые ключ и, соответственно, новые данные.
В-четвертых, не обязательно кешировать все и вся. Скорее наоборот - простые запросы лучше не кешировать, из базы часто быстрее получить результат, чем из файла (да и базы на сегодняшний день сами по себе много чего кешируют). И этот момент можно использовать во благо, например сделать систему тегов для файлового кеша...
В-пятых, ... Хотя нет, хватит пока и основ ).
По сути, в этой области ничего нового не придумано и все давно изучено. Есть 2 вида хранения кеша (память, диск) и 2 типа кеша (плоский, структурный), все остальное - их производные. Примеры:
1. Файловый кеш (диск, плоский)
2. Мемкеш, APC (память, плоский)
3. noSQL, mySQL (да-да, mysql тоже можно использовать для кеширования; память/диск, структурный)
По опыту, memcache, на данный момент, самый удобный и практичный.
Сделку завершили, сайт и домен забрал. Спасибо за сделку.
И как гугл его окупает? ) Да и сделал он его уже достаточно давно, по меркам интернета.
Сделать сервис, который будет выплачивать деньги пользователям - можно, но тогда и траф будет говно.
