evnuh

Делать по потоку на коннект - худшая идея.
Использовать редис для межпроцессорной коммуникации - хорошая идея.
Как разбить задачи по воркерам. Думаю, отличным вариантом будет равномерно всё размазать на все ядра, то есть, главный поток выступает неким роутером, который по очереди раздаёт (по очереди воркеры сами забирают) себе инфу пришедшую по сокету в главный процесс. При этом всё можно разбить по игрокам, а привязывать на каком из поток обрабатывается какой игрок по его id, например. Для всего этого можно использовать редис, но лучше не поленитесь и хотябы чуточку почитайте про zeromq, там и сокеты, и concurrency framework и message passing.

нет

Если говорить про скорость загрузки и отрисовки сайта - то есть хороший иструмент wbench, он вам прогонит через хромиум загрузку сайта без кешей много раз, и у вас будет примерное представление сколько секунд пользователь ждёт до момента, когда сайт уже полностью функционирует.

Если всё равно комментарий фильтруется, то зачем его хранить в БД? Плюс это больше возможностей заинжектить код вам.

Собсно, как делаем мы - toroid.org/ams/git-website-howto . Это процесс деплоя. В свой локальный репозиторий добавил два ремоута - prod & test. Собсно сначала выкладываю на тест одной командой
git push test master
потом, если всё хорошо, уже на прод
git push prod master
Если нужны какие-нибудь пост-обработки, то они происходят на сервере через хуки гита.

Начинание похвальное, но вы и вправду вдаетесь сильно в детали. Да, можно людям рассказать что был такой-вот интерпретатор, даже работал, но код-то им зачем показывать, и уж тем более, зачем на таком уровне разбираться с тем, как был устроен тот самый интерпретатор?

Научитесь пользоваться гуглом. Далее вы просто обязаны потратить полчаса и прочитать полностью git-scm.com/book/ru. После этого вы сами сможете ответить на все вопросы.
P.S. совет @Fesor сомнителен, т.к. мы не знаем, как устроен ваш код, но лучше конечно чтобы ваш код и код CMS были в разных папках и контроллились разными репозиториями.

Смотрим чуть ниже моего ответа, блок "Похожие вопросы". И находим там решённый вопрос: Как всё-таки оптимально импортировать из XLS в PHP?

> brew help
Example usage:
  brew [info | home | options ] [FORMULA...]
  brew install FORMULA...
  brew uninstall FORMULA...
  brew search [foo]
  brew list [FORMULA...]
  brew update
  brew upgrade [FORMULA...]
  brew pin/unpin [FORMULA...]

Скорее всего, чует моё сердце, вам подойдёт команда
> brew uninstall [app_name]

Как организовать контроль версий двух одинаковых сайтов?

Подожди осени, а осенью подожди зимы, после НГ обычно тоже обновляют процы / твердотелки. А зимой уже можно и весны ждать, там глядишь на конференции новую модельку покажут.

Неверные ответы вам дают и вы тоже неверно мыслите.
Гит как раз и создан был для сохранения состояния, то есть каждый коммит - это снапшот кода. Некий аналог ctrl+s, если хотите. Коммиты не должны быть привязаны ни к задачам, ни к фичам, ни к багам, ни к чему остальному. Можно хоть каждые 5 секунд коммитить по букве, и ладно. Для управления фичами/багами/etc. есть ветки (не даром они очень легкие). Одна фича - одна ветка. Внутри ветки хоть 500 коммитов, но как только работа завершена - делается pull request и фича мерджится.
На историю коммитов никто не смотрит, смотрите на дерево коммитов.