Что это? Как это? Зачем это?

Убедительная просьба: не уверен - не пиши. Советы типа: "нужно, кароче, тупо оптимизировать свой код и все будет зашибись" - оставлять в своей базе знаний и не пускать дальше.

_____________
Гнусный социопат с комплексом Бога.

А что ты ожидаешь услышать?
Так и есть. Понимать наиболее ресурсоёмкие точки проекта, и их "упрощать", кешировать, переделывать, и т.д.
Писать не в стиле "что бы работало", а что бы работало хорошо и быстро. Для этого надо понимать что такое запросы, и что такое, к примеру 3 джоина в запросе(к примеру вот статейка http://habrahabr.ru/post/44807/). И что с ними делать

А "зачем это", да это даже простая "лакмусовая бумажка". Человек который работает в хайлоадом уже понимает множество тонкостей, который пригодятся всегда и везде

_____________
Если не говорить пользователям, что Linux это "Сложно и страшно", то им совершенно всё равно, в чём не разбираться

разработка под высокие нагрузки = хороший код + горизонтальное масштабирование

Писать код который сможет работать с десятком серверов memcache и БД, у которой таблица user на 3х разных серверах

Достигнут предел вертикального масштабирования, а проект начинает тормозить

_____________
VPS от 5$, первые 2 месяца - бесплатно.

Здесь я удивился. Можно не "в лоб", а более подробно разобрать эти три пункта?

_____________
Гнусный социопат с комплексом Бога.

Когда реч идет очень высоких нагрузках, то тогда сразу встаёт о масштабируемости проекта т.к. если сейчас даже ты все наоптимизируешь ООООЧЕНЬ хорошо и снизишь нагрузку, то что будет когда начнется реклама продукта? и пойдут 5 раз больше трафика? опять оптимизация? почему сразу недооптимизировал до максимум? в один прекрасный момент оптимизации просто упрешся в стену когда опитимизировать будет нече.

И вот тут на помощь приходит масштабируемость, и у неё есть 2 основных понятия:

вертикальная (споты) - когда в армках одной бд записи одной таблицы деляться на под таблицы по признаку дабы оптимизировать скорость работы. (пример была таблица люди, стало две таблицы: мужчины, женщины)

горизонтальная (шарды) - это когда разносятся на разные сервера данные, и ладно когда по начало у вас вся одна таблица находится на одном сервере, но стратегия масштабируемости должна быть универсально так чтоб сходить в соседний магаз купить еще 10 серверов моментом накотить подготовленные дистры и в бой их. (у меня такого не разу не было но вот мой начальник рассказывал что уходил с работы у них было 6 серверов вернулся утром уже 8, оказалось ночью рекламу запустили)
в итоге у нас есть какие то алгоритмы по которым мы вычислем на каком шарде и в каком споте лежит запись и подключаемся туда и достаём её.

3. И само сабой если еще при вертикальном масштабируемости можно делать join внутри запрос то при вертикальной ты уже не сделаешь данные на нескольких сервах.

3. order для бд это один из самых тихих операций, соответсвенно её делать нельзя, тут на помощь приходят инструменты поиска сфинксы яндексы и т.д. (хотя я работал ток со сфинксом прикольная штука), дак вот эти вещи по умолчанию выдают в нужной сортировке, или же по ревалентности поиска.

4. autoincriment бд не получится использовать разные сервера.... опять таки мешают, мы юзаем для это мемкеш.

Велосипеды строить???
На чем, на чем, а на хорошей основе в виде того или иного фреймворка не стоит пренебрегать даже в высоконагруженных системах. И не поверите пишут высоконагруженные проекты и на Symfony, так как структура кода очень хорошая, возможности впечатляющие, расширяемость отличная.
Человекочасы обходятся дороже новой железки. Проще выбрать подходящий фрейм. сложить за пол года проект и уже получать с проекта прибыль(затратив на пару новых серверов монетку), чем оплачивать команде разработчиков ЗП в течении года.

_____________
Mysql, Postgresql, Redis, Memcached, Unit Testing, CI, Kohana, Yii, Phalcon, Zend Framework, Joomla, Open Cart, Ymaps, VK Api

Компания, в которой я работаю, основной платформой использует Symfony2. Расширяемость потрясающая, отдел архитекторов, наращивают его всем что нужно, без проблем (камень в огород Twin'у, про его "...находится в рамках фрейма, и не шагу в бок..."). И я тоже собсна без труда расширяю его чем хочу, без вреда остальным модулям, которые очень часто отваливаются в "велосипедах". А используем мы различное кеширование, туда входит "Varnish", все летает, все четко) Хоть и симфони достаточно тяжелый в процессорном эквиваленте, из-за чистого ООП (камень в огород Joker, считающий что ООП в ПХП еще не доросло до "нормального ООП")

Полностью не согласен! Как уже сказали выше, стоимость человекочасов выйдет намного дороже, чем железо. Про то, почему и т.д не буду спорить. Заколебался) Тебе надо просто с этим работать, и видеть как с помощью GIT'а и четкой архитектуры, и кода, делаются стабильные и легкопонимаемые модули) В котором вновь прибывший новый прогер разберется за несколько часов.