Во-первых, нужно узнать истинные причины нагрузки. Для этого было бы неплохо взглянуть в Логи сервера, или сделать свою статистику вызовов страниц. Последний вариант более удобен, т.к. логи сервера забиты информацией о картинках, баннерах, кнопочках, html, js, css и прочей информацией, которая не создает нагрузки на PHP.
В данном случае нельзя полагаться на графические счетчики рейтинговых систем и систем статистики, т.к. они не показывают главного источника нагрузки - поисковых роботов и спам-ботов!
Во вторых. Необходимо начать фильтровать доступ к сайту, - делать запрет для спам-ботов. Существует много методик их вычислять.
В третьих. Нагрузка большого проекта порождается не количеством посетителей, а количеством страниц в проекте. Чем их больше, - тем больше страницы вызываются поисковыми ботами. В среднем, для проекта средней крупности, нагрузка ботов превышает 90% от общей нагрузки. (к примеру, - статистика рядового и не очень крупного проекта до начала работ по снижению нагрузки. За сутки, - 91000 вызовов страниц, не считая php-скриптов рекламных баннеров, счетчиков статистики и пр. Из них, - около 4000, - это живые люди.)
А посему, - необходимо использовать директиву crawl-delay для того чтобы манипулировать паузой между вызовами сраниц поисковыми ботами. Эту директиву хорошо понимают Яндекс, Yahoo, MSN-bot (live) и пр.
Для воздействия на Гугл необходимо указать периодичность вызова страниц через панель управления вебмастера.
Всяким там китайским и прочим поисковым ботам (если они Вам конечно не нужны), - запрет в robots.txt
Далее - необходимо отфильтровать мусорные страницы. Здесь речь идет как про robots.txt, так и про 404 для несуществующих страниц.
Очень часто, индексы поисковых систем забиты мусорной информацией. Часто причиной этого служат пагинаторы. Пагинатор для несуществующей страницы должен отдавать 404. Часто бывает, что вы, например, изменили расположение рубрик в доске объявлений, и идентификатор популярной рубрики с большим количеством объявлений резко стал идентифицировать малопопулярную рубрику, в которой к-во страниц в сотни раз меньше. Поисковые системы должны это увидеть в виде статуса 404.
Особого внимания заслуживают парковые домены. Стоит взвесить их целесообразность,. Даже один парковый домен заметно повышает нагрузку от поисковых ботов, если это дело пустить на самотек и не давать ботам никаких директив
Теперь насчет кеширования.
Многие поисковики (а ведь основную нагрузку создают именно они) прекрасно понимают статус 304 Not Modified! Грех не использовать это. По этим же соображением, желательно стараться избегать показов случайно-сгенерированного или частоменяющегося содержимого на страницах с конечной информацией, если вы генерируете HTTP_IF_NONE_MATCH на основе контрольной суммы, хеша содержимого страницы.
В ряде случаев, целесообразней использовать HTTP_IF_MODIFIED_SINCE.
Одна из самых длительных операций PHP - это принт. Поэтому, необходимое ее максимально сократить. Используйте сжатие страниц перед их отдачей. Закрывайте перед отдачей соединение базы данных, чтобы не превысить лимита соединений.
Теперь по поводу кеширования. В ряде случаев, персональную информацию (как то персональное меню авторизованного пользователя вместо авторизационной формы) можно внедрять в "дырку в теле кеша", в своеобразное динамическое окно в кеше, тем самым сильно сэкономить дисковое пространство. Посмотрите, как это реализовано в Smarty или
http://popoff.donetsk.ua/text/work/light/
Для точеной очистки кеша используйте "метки" кеша. Опять же:
http://popoff.donetsk.ua/text/work/light/
http://framework.zend.com/manual/en/zend.cache.theory.html#zend.cache.tags
http://dklab.ru/lib/Dklab_Cache/
Такой подход является спасительным для крупного проекта.
>в виде файлов на диске сервера (другие варианты не возможны!)
Думаю, - Вы ошибаетесь. Рекомендую именно БД для кеша. Можно и SQLLite (обычно она есть на всех хостингах).
PS: В принципе, у меня есть небольшая библиотека для кеширования, которая создает "некешируемые, динамические" фрагменты в теле кеша, кеширует http-заголоки, метит кеш, причем ключ метки может содержать множественное значение (для страниц типа &category[]=38&category=25[]&...), широко использует кэширование на стороне клиента, данные хранит в текстовых файлах или в БД.
Но я писал ее давно, она в процедурном стиле, и нет времени красиво ее оформить в виде класса. Поэтому, дабы избежать всеобщего нарекания в свой адрес, я не хочу ее афишировать. Рекомендую внимательно изучить
http://dklab.ru/lib/Dklab_Cache/
и покопаться в
http://popoff.donetsk.ua/text/work/light/
... чё ещё можно сделать?
