Здравствуйте.
Есть сейчас:
Сейчас есть интернет-магазин написанный на кохане(kohana). В качестве базы используется MySQL. Для кеширования используется Memcached.
Одна из самых посещаемых страниц - главная. На главной странице отображаются товары, каждый товар это не один селект в базу, а довольной сложный запрос с join'ами и т.д.(города, категории, количество купленых и другая информация). Кеширование реализованно следующим образом: Кеш проверяется в memcached и если кеша нет, то берутся данные из базы, отрабатывается логику, записывает в memcached(готовый html) и отдается пользователю. Время кеширования - 40 минут, но при этом раз в 5 минут кеш главной страницы удаляется кроном.
Данные о покупках меняются примерно раз в 10 секунд, соответственно надо обновлять закешированные данные на главной странице.
Вопрос: Как более правильно организовать кеширование? (при условии что могут быть разные выборки, пагинация и т.д.)
Я сейчас хочу сделать:
1. Сделать кеш каждого конкретного товара отдельно
2. Сделать "тригерную" систему удаления кеша, т.е. обновился товар, удалился его кеш
3. Есть ли ограничение в memcached на количество ключей и на их размеры?
4. Где можно почитать, как устроено кеширование в крупных/не очень крупных компаниях, что и как кешируется?
И сейчас в меня полял протухшие яйца, потому что все любят холиварить, никто не любит вникать в чужое мнение.
Лично я считаю, делать кеширование на php, это всеравно что носить железобеттонные блоки в руках, потому что дешевле чем нанять кран.
Что касаеться SQL запросов, можно отпимизировать средствами самой базы, например создать фунцию или кешировать запросы самой базой.
Спасибо за ответ!
>>Лично я считаю, делать кеширование на php, это всеравно что носить железобеттонные блоки в руках, потому что дешевле чем нанять кран.
Какие варианты Вы предлагаете рассмотреть?
По поводу SQL, не скажу что у нас там все хорошо, но и не совсем все плохо, т.е. индексы проставлены, вьюшками пользуемся, кеширование самой базы тоже используем(не везде).
kamenevn: я люблю ноду, но это не панацея, есть и другие асинхронные решения. В любом случае у нее проблем с нагрузкой бд и прочим обычно нету, так как можно сохранить все в оперативу, без каких либо дополнительных серверов кеширвоания, а кеш шаблонов - базовая фунция большинства шаблонозаторов ноды.
Alexander Litvinenko: я писал пару легких вещей на ноде, она мне понравилось, но проект переписывать - увы не получится, так что работаем с тем что есть)
kamenevn: потому и говорю про кран... когда дом строили - секономили, а теперь кирпичи докладывать приходится, так как крана небыло, таскать тяжело, вот пару кирпичей по дороге потеряли.
Вводим слой кеша и интерфейс для работы с ним. Это важно, потому что легко позволит переключатся между различными реализациями.
Система хранения кеша должна быть общей для всех процессов PHP. (Пространство ключей)
Конкретная реализация может быть выбрана, поменяна, попробована другая. Начните с Memcache, легко сможете попробовать Redis, если понадобиться что-то посложнее ключ-значение.
В кеш складываем готовый html. Потому что генерация html довольно затратный процесс.
Magento вообще подходит радикально к этому - кеширует все и аяксом подгружает юзер-зависимые блоки (корзину).
Ваш слой кеша позволит инвалидировать данные по событиям. Expiration-time, on-update, on-sale и т.д.
Простой
Простой
Средний
Простой
