Дэн

По оптимизации и масштабированию советую прочитать:
- Для ускорения Yii - 9 шагов по оптимизации Yii
- Для общей стратегии по росту проекта - Разработка под высокие нагрузки

Ошибки репликации случаются довольно часто. Есть удобный инструмент для синхронизации данных для реплик от Перконы: www.percona.com/doc/percona-toolkit/2.1/pt-table-s... Также удобный плагин для мониторинга статуса репликации: www.percona.com/doc/percona-monitoring-plugins/1.0...

В качестве альтернативы - посмотрите на возможность применения шардинга.

Используйте обычную репликацию Master-Slave для резервирования БД (работать с приложениями будет только Мастер). В случае выхода из строя слейва - он пересобирается на фоне. В случае выхода Мастера, Вы переключаетесь на Слейв. Лучше использовать 1 Мастер + 2 Слейва.

MySQL + репликация + шардинг подойдет. Плюсы - технология проверена годами, используется в огромном количестве случаев (Facebook использует MySQL как key-value хранилище). Минусы - балансировку нужно делать руками.

99% оптимизации PHP это
- обязательно использовать APC (или opCache в новых версиях)
- использовать ООП только там, где это реально нужно
- использовать кэширование
- здравый смысл (не загружать списки из 100 элементов, если нужно только 10 и т.п.)

Поддерживаю Fesor - микрооптимизация - это скорее привычки, но никак не методы решения каких-то реальных проблем со скоростью работы.

Что почитать:
- Общие правила оптимальной работы PHP на практике
- Howto по производительности PHP с внутренностями
- 50 micro tips для оптимизации PHP (англ.)

Выбор фреймворка важен, но определяющими характеристиками будет выбор архитектуры и стратегии роста.

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

Советую почитать об архитектуре систем с большой нагрузкой.

Много полезной информации о разработке под нагрузки и оптимизации Web приложений:
ruhighload.com/sitemap

Куча опыта по нагрузкам. Зарубежный ресурс: highscalability.com

Memcached использует алгоритм LRU для определения, какие ключи вытеснять из памяти. Поэтому небольшая нехватка памяти не страшна. Посмотрите статистику вытеснений:
print_r(memcache_get_stats());
Ключ evictions покажет количество вытеснений. Если значение большое, нужно принимать меры. Первое - нужно попробовать оптимизировать расход памяти. Если evictions все равно растут - нужно ставить новые сервера и использовать кластер:

$m = new Memcache;
$m-> addServer('10.10.0.1');
$m-> addServer('10.10.0.2');

На практике использовать удобно только при выборке списков:

$m = new Memcache;
$posts = $m->get(['post1', 'post2',...]);
foreach ( $posts as $post ) echo $post['caption'];

Подробнее тут.

XHprof. Создан в Facebook. Как раз для целей работы на production'ах. Поддерживает специальный режим мерцания для экономии ресурсов при сборе статистики. Есть табличные и графические отчеты.

Аргументы функций в XHprof узнать нельзя никак. Но Вы можете создавать отдельные функции для каждого набора аргументов:

# вместо
function get_users($sort) {...}

# использовать
function get_users_new() { ... }
function get_users_online() {...}

Такой вариант подойдет только для аргументов, у которых есть всего несколько значений. Вы можете использовать графические отчеты для наглядности.

Моя подборка, если кто-то что-то добавит, буду благодарен:

- Клиентская оптимизация Хабры
- Серверная оптимизация Хабры
- Хд - много всего про оптимизацию и масштабирования
- Отчет Pagespeed
- Масштабирование и оптимизация сайтов (англ)

Если Вы используете Nginx, все делается просто. Достаточно включить сжатие gzip и установить Cache-control.

Если у Вас не работает ни сжатие ни кеширование:
* проверьте, перезапустили ли Вы Web сервер
* проверьте, с помощью онлайн инструментов работу сжатия и Cache-control

400 ответы говорят о том, что клиент шлет слишком большой заголовок.

Это помогает
large_client_header_buffers 4 16k;

Попробуйте ставить expires на внешнем Nginx'e (если он смотрит на 80 порт), а не на бекенде.

Попробуйте expires в прошлом времени:
header("Expires: Mon, 26 Jul 1997 05:00:00 GMT");
отсюда

Пройдитесь по чеклисту оптимизации Wordpress. Плюс материал на Хабре.