1. Ни слова о профайлинге, хотя начинать любую оптимизацию нужно с него
2. БД. Кроме индексов и слейвов есть еще денормализация, которая тоже является кэшом. Реплика, кстати, тоже. Встроенное в СУБД кэширование вещь часто вредная, т.к. прозрачная. Прозрачные постоянно-валидные кэши эффективны только когда записей нет.
3. Логика. «Чем меньше запрос, тем легче БД его закешировать» — wtf?
«Ведь вы не уверены, что чтение сессии происходит из ОЗУ а не из файла сессии?» — это как? Пришел человек-Грызлов и все молча поправил?
4. Шаблонизатор. Смарти компилируется в РНР-код. Если у вас нет опкод-кешера, то вы сами себе злобные буратины. Прежде чем переписывать проект со смарти/квики/etc на blitz или ctpp, сядьте и посчитайте когда это окупится. И да, это не кэш.
5. Балансировщик. Это вообще не относится к кэшированию.
Вы же правильно поняли для какой целевой аудитории написано? Вас не смущает упоминание CMS и недоступности прав рута? Есть много промежуточных проектов, в которых люди уже не школота, но еще и не монстры разработки.
1. Статья не про оптимизацию, а про конкретный вответ на конкретный вопрос про кеширование. Профайлинг сюда точно не попадает.
3. Тут практический опыт. Пересмотр запросов во время работ по оптимиации и охранение промежуточных расчетов в кеш спасают нервы и время, особенно когда нет возможности активно кешировать выдачу.
4. Вот чтобы наш читатель и перестал быть ССЗБ я напомнил, что кеширование скомпиленных шаблонов. Это кеширование.
5. Сам балансировщик не относится, но на этом этапе можно организовать кеширование файлов (особенно когда они генерятся на лету).
Я маленький на хабре, чтобы в очередной раз переписывать уже написанные максимум конкретики ;-) А вот обзорной воды без отсылок «это и так понятно» иногда не хватает. Я не прав?
Добавлю:… не только требует много ресурсов, но еще и часто запрашивается.
Иначе усложнится код, а кеш забьется мусором, вытеснив нужные данные — вместо ускорения работы получится замедление и рост нагрузки.
вот так вот клиент начинается статей а потом кричит, дословно «сайт тормозит, пропишите индексы во всей базе». Не хочу никого обидеть но хочется верить что клиенты-бизнесмены правильно поймут статью
И вот как раз на таком месте появляется возможность грамотно, но новом уровне обсудить с клиентом (молодым специалистом) что уже сделано, какие есть планы оптимизации и стоит ли их менять. Можно обсудить приоритеты, а не просто кинуть «мы занимаемся кешированием».
И да, я один раз действительно забыл включить кеширование шаблонов и отсутствие подобного обсуждения с заказчиком заставило лишних пару дней помучаться, не замечая очевидного.
В физ-мат школах на уроки к 10 классу иногда приводят отличника из 6, чтобы он показал как интегралорешаемую задачу можно решить системой уравнений. Иногда очевидные вещи замыливают глаз, и клиент поможет не расслабляться ;-)
Вы уже на месте! Читайте Хабр, специализированные блоги. Ставьте плюсики авторам, которые пишут в доступном вам стиле и задавайте вопросы в комментариях. Очень полезно ходить на технологическую часть конференций вроде iForum. А с книгами плохо: пока напишешь — уже устарееет.
видно что вы старались, спасибо, читать было интересно, но осталось очень много недомолвок и оговорок которые нужно было поставить в виде ссылок по теме, что-бы у опытного человека не осталось к вам вопросов, а у новичка не вскипел мозг.
И так простыня вышла. Для песочницы уже великовато. Может позже напишу более конкретизированную статью и дам ссылку отсюда.
Про недомолвки: постараюсь понаходить более тематические узкие посты, чтобы дать якоря. Если у кого в закладках что есть, кидайте послания — с удовольствием расставлю.
Абсолютно согласен. Но это вне рамок статьи и я надеялся, что в комментариях умные люди упомянут такие ньюансы. У каждого приложения свои задачи, приоритеты и особенности. Универсального решения нет. Где то установка времени жизни будет самым оптимальным решением, где то такой подход будет вредным. Голову на плечах никто не отменял.
Что кешировать?