- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
В 2023 году Google заблокировал более 170 млн фальшивых отзывов на Картах
Это на 45% больше, чем в 2022 году
Оксана Мамчуева
Как удалить плохие SEO-ссылки и очистить ссылочную массу сайта
Применяем отклонение ссылок
Сервис Rookee
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Доброго времени суток! На примере опенкарта хочу понять принцип работы файлового кеширования для шаблонов. Вопрос в следующем - opencart сам по себе очень тяжел и дает нехилую нагрузку на базу, от части это связано с тем, что изза мультиязычности в одном запросе используется до двух десятков LEFT JOIN-ов. Но в тоже время он не тормозит, что позволяет предположить(ну и опыт подсказывает), что у него хорошее файловое кеширование, и лишний раз бд не дергается.
Вопрос - как организовано кеширование и как понимать когда это кеширование сбрасывать, а когда оно ещё октуально. Первое что приходит в голову - держать сохраненный блок контента в текстовом файле, и от него считать md5 и сверять его с ключевым md5 из базы для конкретной страницы. При обновлении позиции\категории просто этот md5 сбрасывать. Но тут есть ньюансы вроде пагинации, различного вида сортировок (убывание\возрастание цены\названия).
Вопрос номер два - какие эффективные виды кеширования (кроме мемкеша) актуальны на данный момент и в чем их плюсы\минусы. Если приведете аргументы в плоскости интернет-магазинов будет вообще замечательно. Спасибо :)
а разве у opencart нет своего кэширования? был же!
Вопрос кеширования - слишком сложный, чтобы описать все нюансы в 1 посте.
Кешировать можно html-код, результаты запросов повторяющихся блоков, результаты поиска, слабые места.
Более конкретно ставьте вопрос.
Для разных задач - подходят разные решения.
Вопрос - как организовано кеширование и как понимать когда это кеширование сбрасывать, а когда оно ещё октуально.
Инвалидация кэша наряду с именованием переменных...
По поводу различных "сортировок" - их действительно имеет смысл кэшировать?
Быть может, сначала определить узкие места.. что именно создаёт нагрузку?
Вопрос - как организовано кеширование и как понимать когда это кеширование сбрасывать, а когда оно ещё октуально. Первое что приходит в голову - держать сохраненный блок контента в текстовом файле, и от него считать md5 и сверять его с ключевым md5 из базы для конкретной страницы. При обновлении позиции\категории просто этот md5 сбрасывать. Но тут есть ньюансы вроде пагинации, различного вида сортировок (убывание\возрастание цены\названия).
Во-первых, кто Вам сказал, что джоины непременно заставят базу тормозить? Правильное использование ключей спасет в 99.99% случаев. Будь хоть сотня джойнов, при не большом размере таблиц и правильно настроенных индексах - не почувствуете.
Во-вторых, основный принцип кеширования - сохранить часто запрашиваемую, но редко изменяемую информацию. Чаще всего, в кеше сохраняют не фрегменты страниц (хотя и это бывает оправдано), а результаты запросов - меньше весят, проще проверить валидность кеша.
В-третьих, пагинация, сортировки, фильтры и пр. - это отдельные кеши, никак не связанные между собой. Ведь даже по умолчанию все это используется, часто скрыто. Поэтому, решение простое: смотрим все параметры, генерируем ключ и по нему сохраняем (в дальнейшем получаем) данные. Например:
$cache_key = "catalog_{$sort}_{$desc}_{$filter}_{$page}";
Изменился любой параметр - получаем новые ключ и, соответственно, новые данные.
В-четвертых, не обязательно кешировать все и вся. Скорее наоборот - простые запросы лучше не кешировать, из базы часто быстрее получить результат, чем из файла (да и базы на сегодняшний день сами по себе много чего кешируют). И этот момент можно использовать во благо, например сделать систему тегов для файлового кеша...
В-пятых, ... Хотя нет, хватит пока и основ ).
Вопрос номер два - какие эффективные виды кеширования (кроме мемкеша) актуальны на данный момент и в чем их плюсы\минусы. Если приведете аргументы в плоскости интернет-магазинов будет вообще замечательно. Спасибо :)
По сути, в этой области ничего нового не придумано и все давно изучено. Есть 2 вида хранения кеша (память, диск) и 2 типа кеша (плоский, структурный), все остальное - их производные. Примеры:
1. Файловый кеш (диск, плоский)
2. Мемкеш, APC (память, плоский)
3. noSQL, mySQL (да-да, mysql тоже можно использовать для кеширования; память/диск, структурный)
По опыту, memcache, на данный момент, самый удобный и практичный.
2. Мемкеш, APC (память, плоский)
Как-то странно, рядом помещать две никак не связанные вещи. Кэш данных и кэш опкода.
---------- Post added 21-09-2012 at 13:22 ----------
UPD. Извиняюсь, данные в APC тоже можно кэшировать, не знал. Спасибо.
Продолжайте, я для этого и создавал топик :)
меня интересуют хай лоады впринципе, опенкарт лиш указан для примера
Как будет происходить инвалидация кеша запроса?
меня интересует сам принцип, хотя идея ниже
$cache_key = "catalog_{$sort}_{$desc}_{$filter}_{$page}";
крутилась в голове, но из неё появляется следующий вопрос - а если добавился новый товар в середину списка с ценами? делать инвалидацию всей категории во всех вхождениях кеша?
это пока теория, хочется не наступать на грабли в будущем
При джоине создается виртуальная таблица куда помещаются выбранные данные, хоть это и временно, это несет неудобства в плане потребления ОЗУ. В моем проекте на одной базе будет крутиться десяток проектов, использование множественных LEFT JOIN мне кажется нецелесообразным, т.к. сервер быстро завернется.
Спасибо за направление, буду самообразовываться
все с ним хорошо, но при нехватке памяти вытесняются старые данные, соответственно в определенный момент он просто потеряет смысл, т.к. инфа там будет храниться не более n времени
тоже спасибо, будет время обязательно почитаю, направление интересное
меня интересует сам принцип, хотя идея ниже
$cache_key = "catalog_{$sort}_{$desc}_{$filter}_{$page}";
крутилась в голове, но из неё появляется следующий вопрос - а если добавился новый товар в середину списка с ценами? делать инвалидацию всей категории во всех вхождениях кеша?
Нормальная (и единственно правильная) практика: при изменении данных в хранилище - удалить кеш, связанный с этими данными. В Вашем случае - удалить кеш для запросов данного типа. Это будет удобно сделать, если каждый тип кеша скидывать в свою папку.
При джоине создается виртуальная таблица куда помещаются выбранные данные, хоть это и временно, это несет неудобства в плане потребления ОЗУ. В моем проекте на одной базе будет крутиться десяток проектов, использование множественных LEFT JOIN мне кажется нецелесообразным, т.к. сервер быстро завернется.
Да ладно? ))) Я, пока что, знаю только один проект, на котором не используются джойны. Но знаю кучу других, на которых джойны используются в полную силу. Есть и цифры: 250-300к уников в сутки на 1-м сервере базы данных. С кучей джойнов.
все с ним хорошо, но при нехватке памяти вытесняются старые данные, соответственно в определенный момент он просто потеряет смысл, т.к. инфа там будет храниться не более n времени
Тут все зависит от кривизны рук, если честно. Вообще, это даже хорошо - в кеше только те данные, которые нужны. Да и заполнить 2-4 гига памяти данными из базы - довольно проблематично, если честно. Посчитайте сами: если все данные из базы на 1 товар весят 2-3 кб (а это ОЧЕНЬ МНОГО), то для заполнения 2-х гигов памяти надо 700-1000 ПОПУЛЯРНЫХ товаров, т.е. таких, в которые заходят много разных людей и часто. Реальна ситуация? Думаю нет... А если да - то значит не проблема найти 16-64 гига памяти, т.к. магазин уже ОЧЕНЬ популярный ;).
предложите вариант с мультиязычностью для всего. начиная от названий категорий заканчивая названиями различных типов и видов сортировок по определнному параметру для категории. В итоге имеем только для товаров 12-15-20 таблиц с инфой по каждой характеристике и каждому языку.
Используются не значит лучший вариант, это впринципе самый простой вариант организации полноценной мультиязычности. Но. Без нормального кеширования при 100к+ запросов в день под такую базу прийдется выделять очень нехилые ресурсы, что не есть оптимально
и в чем может быть кривизна рук, если у мемкеша аж 4 команды и десяток параметров настройки. Да и 2-4 гига под _только мемкеш_ это ресурсоемко, не кажется
давайте представим что на 1 базе крутится десяток проектов средней популярности\тематики, думаете не набереться и больше? :)
предложите вариант с мультиязычностью для всего. начиная от названий категорий заканчивая названиями различных типов и видов сортировок по определнному параметру для категории. В итоге имеем только для товаров 12-15-20 таблиц с инфой по каждой характеристике и каждому языку.
Вынести языковые данные в файлы - APC/eAccelerator поможет в работе.
Используются не значит лучший вариант, это впринципе самый простой вариант организации полноценной мультиязычности. Но. Без нормального кеширования при 100к+ запросов в день под такую базу прийдется выделять очень нехилые ресурсы, что не есть оптимально
100к уников в сутки в инет-магазине и нет средств на поддержку ресурса? Ладно, в сторону подобное... По технической части: я не говорил что не нужен кеш, я сказал, что надо кешировать только то, что требуется, а не все подряд.
и в чем может быть кривизна рук, если у мемкеша аж 4 команды и десяток параметров настройки. Да и 2-4 гига под _только мемкеш_ это ресурсоемко, не кажется
В реализации, а не в настройках ;). Если хранить вместо данных еще и разметку (а я еще видел как и js+css был в закешированных данных) - вытеснение данных будет идти намного быстрее, верно? 2-4 гига - это мелочь, на сегодняшний день. И поверьте, проще и дешевле поставить 32 гига памяти, чем наглухо оптимизировать скрипт и потом его поддерживать.
давайте представим что на 1 базе крутится десяток проектов средней популярности\тематики, думаете не набереться и больше? :)
Думаю, что если есть десяток проектов средней популярности - можно найти деньги и поставить то железо, которое обеспечит комфортную работу не только базе, но и разработчику. А то получается, что хотите выделить по 200-400 метров памяти на каждый проект и требовать адекватной работы от него. Конечно, такое возможно, но маловероятно.
Кстати, при 100к униках и таких сложных требованиях к запросам, есть проще вариант для кеширования: сохранять отдаваемую страницу целиком в файловый кеш на относительно не большое время (1-60 сек) и следующим посетителям отдавать напрямую через apache/nginx, минуя php. Плюсы: минимальное потребление ресурсов, быстрая работа, минимум конфигурации (при использовании nginx - он сам все это может делать, даже код менять не надо).
P.S.: как-то Вы путаетесь в параметрах... то один проект на 100к и кеш для него продумывается, то десяток средних и думаем о расходе ресурсов под них. Разные задачи - разные решения.
Задача - сделать универсальный движ для 10 интернет-магазинов, и так как это реализация скорей для набить руку и повысить свой уровень, меня интересует вопрос нагрузки. По поводу файлового кеша я и думал как то так организовать, но нужно более детально продумывать, т.к. подобных моментов и узких мест будет множество.
задача как раз таки одна, так интереснее :)