Алексей Сундуков

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

Ну как бы задача url routera лежит не на шаблонизаторе, а на самом фрейморке.
Что бы было проще можно взять любой фреймфорк: Zend, Yii, Symphony, CI и т.д.
На любой из них можно легко прикрутить шаблонизатор

ИП на УСН 6% — очень небольшие налоги

У меня нетбинс виснет гораздо чаще чем раз в пол года). Хорошая программа.

Авангард ИП:
все затраты ВК 0,15% мин 500 руб
плата за обслуживание 0
все делаю только через инет банк, никаких оригиналов и прочих реальных бумажных документов
при необходимости получить рубли делаю конверсию там же, хороший курс
там же в авангарде рублевый и валютные счета на физлицо куда перевожу со счета ИП, комиссия за внутрибанковский перевод 0, обслуживание тоже 0, при условии каких-то там оборотов по картам

habrahabr.ru/post/101440/

LFS.

Gentoo или LFS (совсем хардкор).

90% цсм с такими функциями, разве что 4 пункт не часто встречается

jabber. Плагины для хранения логов есть. Видео/аудио через jing реализованы во многих клиентах.

+1000 Jaber. Аргументы следующие:
1. Свой сервер (не зависите от внешних серверов) своя политика безопасности, настройки и тд…
2. Шифрование. Любое, вплоть до маниакальнонаправленного!
3. Клиенты подо все! Включая любые недокомпьютеры и сматфоны.
4. Возможность говорить и голосом, а при прямых руках и видео…

jabber

Процессор не сильно важен. Лучше с меньшим количеством ядер, но с частотой побольше.
Диски лучше sas. Оперативки побольше.
Узким местом легко окажется сетевой интерфейс при правильной настройке.

Я считаю, менять железо чаще, чем раз в 3-5 лет — это потворство потребительским инстинктам и уплата дани транснациональным корпорациям. В общем, это плохая затея.

Говорят, на визуальном быстродействии гораздо ощутимей сказывается замена HDD на SSD, нежели замена C2D на i7.

Мегагерцы нынче не очень важны. Вот 4М кэша это хорошо.

А вообще как известно «Система работает со скоростью самого медленного элемента» так что сравнивать две системы только по процам это грубо.

Если у вас происходит только раздача контента, без его обработки, вам практически не нужен процессор. Практически у вас основное узкое место это диски.
Такое решение надёжнее и обычно дешевле делать не на одном мощном сервере, а на нескольких довольно простых.

Возможно имеет смысл сделать пару основных хранилищ и несколько кеширующих фронтэндов с ssd, если есть часть файлов запрашиваются заметно чаще других.
Если запросы размазаны по всем файлам, имеет смысл брать несколько простых однопроцессорных 1U серверов по 4 винта в каждый, побольше памяти. И распределять запросы между ними.
Такие решения и надёжнее, и обычно дешевле чем одиночный сервер, который справится с такой же нагрузкой. К тому же проще масштабироваться потом, добавляя постепенно типовые и недорогие серверы, с одинаковой конфигурацией железа и ПО.

Создайте группы в популярных соц.сетях. Быстро и сердито.

Предпочесть PostgreSql, плюшек и возможностей больше -> меньше геморроя с перепиливанием СУБД-зависимого кода.

Существует несколько ситуаций:

• Если проблем в сети нет, то отвалившийся клиент «закроет» порт и сервер получит RST на свои пакеты, т.е. сервер «увидит» падение коннекта практически сразу.
• Если существуют проблемы в сети, когда ответ от клиента не приходит, то есть параметры, которые отвечают за таймауты (выставляются через sysctl):
  

  tcp_retries1
  Целочисленная переменная tcp_retries1 определяет число неудачных попыток, после которого должна быть передана информация на сетевой уровень. В соответствии с RFC минимальное значение составляет 3 (по умолчанию установлено именно это значение), что соответствует периоду приблизительно от 3 секунд до 8 минут в зависимости от значения тайм-аута повторной передачи RTO (Retransmission time-out).
  
  tcp_retries2
  Целочисленная переменная tcp_retries2 определяет число неудачных попыток, после которого существующее соединение уничтожается. В соответствии с RFC 1122 тайм-аут должен быть больше 100 секунд. Такое значение слишком мало и по умолчания установлено число попыток 15, соответствующее тайм-ауту приблизительно от 13 до 30 минут в зависимости от RTO.
  

Все параметры описаны в документации к исходинкам ядра (Documentation/networking/ip-sysctl.txt)

Также эти параметры влияют на все TCP соединения данного сервера. Если нужно «тюнить» для конкретного своего приложения, то можно использовать параметр TCP_USER_TIMEOUT для tcp-сокета. Указывает время в миллисекундах ожидания подтверждения (ACK) данных. Параметр появился в 2.6.37.
Для более ранних ядер можно мониторить исходящую очередь на сокете, и если она не уменьшается какое-то время — значит что-то случилось.