Еще раз добрый день, попытаюсь донести до масс, кому действительно интересны высокие нагрузки, немного разъяснений. Я не будут останавливаться на частностях, которые Вы уже должны знать, если Вы их не знаете или не можете узнать используя google, задумайтесь и лучше поручите эту работу кому-то другому.

Во-первых, что такое highload (высоконагруженный) проект, это проект ну хотя бы от 1 млн. хитов в день, хотя это тоже субъективно - правильнее rps - request per second, то есть количество запросов в секунду, может быть проект с посещаемостью 100000 хитов быть более нагруженный из-за пиковых моментов, чем сайт с 1000000 хитов.

Тезис №1
Преждевременная оптимизация корень всех бед.

Если Вы никогда не делали аналогичный highload проект, Вы НИКОГДА не скажите где у Вас будет узкое место, а посему я ( и такое классики как Фаулер, например ) советую Вам не оптимизировать заранее. Это не значит, что можно писать криво, наоборот делайте все правильно, красиво, гибко. Использование ООП и Design Patterns (шаблонны проектирования), только поощряются, а не как многие заблуждаюсь, советуют наоборот. Сейчас мы рассмотрим почему.
Раньше, дела обстояли так, что не было OP cache программ (те кто берут php код и сохраняют его результат интерпретации в кэше), что приводило к тому что интерпретация большого кода (а ООП код всегда несет в себе излишество) существенно замедляла отдачу. Теперь же есть много таких программ, я лично считаю лучшей бесплатную Xcache (которую, кстати, начинают ставить даже на простых хостингах).
Дальше, вспоминая 1 тезис, мы не знаем где будет узкое место, а когда сделали проект и увидели под реальной загрузкой что в таком-то месте у нас тормозит ( для этого можно например погонять в Xdebug) то мы всегда может сделать хак который ускорит это место убрав оттуда ООП или другой код внедрив или дополнительный кэш этого места.  Всегда можно от высокого спустится к низшему. А, ухудшая изначально свой код, Вы делаете непоправимое - скоро крупный проект выйдет у Вас из под контроля и Вам придется переписывать заново его или мучаться с поддержкой этого жиле.

Тезис №2
Умный в гору не пойдет, умный гору обойдет.

Любой highload это масштабирование, масштабирование бывает 2 видов:
- вертикальное, когда увеличивают мощность сервера.
- горизонтальная, когда нагрузку разносят на несколько серверов.
Так вот, хайлоад предполагает легкую горизонтальную расширяемость проекта, заложите это в основе своей архитектуры, и все у Вас будет хорошо.
Масштабировать лучше начать (повторюсь, надо смотреть на проект, всё тут очень и очень уникально) с разнесения на 3 сервера:
1)    Статические файлы. Поставить веб сервер Nginx, он замечательно справляется с отдачей статических файлов. Сюда относиться js, css, картинки любой контент и если вы используете html кэш, который потом собираете  SSI директивой.
2)    Логика. Я бы посоветовал тут поставить lighttpd.
3)    Базы данных. Ставим MySQL и memcache на отдельный сервер, желательно чтоб на нем было побольше и побыстрее оперативной памяти.
Когда и если Вам перестанет хватать этих серверов, Вы спокойно можете поставить еще один и с помощью аппаратного балансировщика нагрузки или программного (например nginx) и увеличить в двое ресурсы. Единственная сложность MySQL сервер, так как там надо поддерживать актуальную информацию, а она часто изменяется, то можете либо при вставке или изменении делать их сразу на всех таблицах или сделать master – slave и синхронизировать контент с мастер на слейв с какой-то периодичностью по cron. Делать кластер не советую на MySQL заметно падает производительность, тут уже стоит посмотреть на другие СУБД.

Тезис №3
Кэшируй все что можно.

Тут думаю все понятно, просто храним в кэше все что можно, чтоб не нагружать сервера, в основном это касается запросов в базу данных, как мы видим из предыдущего тезиса, это самое узкое место и сложных расчетов, например статистических. Для кэша советую использовать memcache.


Заключение.
Соблюдая эти 3 простых тезиса, Вы может и не сделаете google, но выдержите любую адекватную нагрузку в разумных пределах, а если ее Вам не будет хватать, то тут уже думаю, Вас будет меньше всего заботить, как это реализовать, ведь вы сможете себе позволить курировать этот проект с Гавайских островов!