Иван

Разверни демку от симфони и xdebug'ом пройдись несколько раз по пути запроса клиентского. Думаю, что сразу много интересного увидишь :) Там и события, и компиляция, и DI, и слабая связанность, и много всего другого. Самое главное, что реализовано толково, я бы даже сказал академически правильно. Ну насколько это возможно сделать на "академически странном" языке php.
А затем попробуй на этом же фреймворке реализовать какое-нибудь простое приложение, например, которое просто принимает от клиента запросы по АПИ и что-нибудь делает простое.

В распараллеливании смысл, конечно, есть. Просто это должно делаться на всех уровнях. Апач не использовал уже несколько лет, поэтому тут ничего сказать не могу, но судя по описанным симптомам, затыком у тебя является БД.
Конкретно с firebird не работал, но наверняка её можно распараллелить через репликации.
Т.е. сейчас у тебя получается 3 php-скрипта делают запросы к бд. Бд обрабатывает запросы синхронно, поэтому никакого выйгрыша в скорости не получается. Можно либо в настройках бд поискать асинхронную обработку запросов, но врядли там такое есть, либо реплицировать бд по типу мастер-слейв и запрашивать с разных слев-серверов бд данные, тогда прирост в скорости будет.

Вы представляете себе, что Модель это что-то конкретное, но на деле это просто абстрактный слой и Вы сами решаете какие классы в него входят, а какие нет. На деле в модели содержится ВСЁ, что связано с данными и бизнес-логикой над ними. Далее идет уже реализация, которая может быть очень и очень разной. Например, есть шаблоны проектирования ORM DataMapper и ActiveRecord. Они чуть ли не противоположно разные в реализации, но они обе модели. При этом есть более низкоуровневые архитектуры, например Domain Driven Development и Data Driven Development. В обоих случаях уровень Модели может быть размазан на несколько слоёв приложения.
Я сейчас работаю в проекте с Domain Driven и там модель размазывается просто на кучу слоёв приложения. Как она будет размазана завист от того, какие слои для своего приложения Вы сами определили изначально.
И Ваше утверждение, что большинство фреймворщиков ничего не понимают в этом - полная глупость. Фреймворк Симфони - это просто эталон академичности проектирования в пхп. На его основе Ларавель - тоже достаточно грамотный фреймворк. Есть еще Yii, которые пошли другим путем, но тоже очень четко разделяют внутри модель MVC, хотя и дают много возможности наговнокодить и всё смешать в кучу.
Тут скорее Вы не понимаете, что модель - это не что-то конкретное, а лишь один из 3х компонентов, из парадигмы mvc, ответственный за хранение и изменение состояния данных. Реализаций может быть столько сколько существует программистов и даже больше.
Еще более неопределенное - это то, как взаимодействуют эти 3 компонента из MVC между собой. Они могут на основе событийной модели взаимодействовать, или явно вызывая друг друга, и еще огромным числом разных способов.
Касательно Вашего примера, то Вы описали слой хранения данных, переходящий в модель. Моделью, в Вашем случае, является 3ий уровень - строка таблицы(ну может и таблица тоже). 1ый уровень у Вас - это уровень, который должен синхронизировать модель с хранилищем данных. Причем таких "синхронизаторов" может быть несколько и хранилища могут быть очень разными. Например ORM и ODM. Они будут проэцировать и синхронизировать модели с хранилищями данных, но по сути к моделям они не относятся, хотя если нам нужно их всё же определить только в рамках MVC, то это конечно же будет моделью. Но в mvc есть много вещей, которые не относятся ни к одному из этих 3х компонентов, а являются связующими звеньями этих компонентов, например те же ORM, ODM, валидаторы(иногда их в модель зашивают, хотя они могут использоваться и во вне), роутинг, событийные компоненты, логер и прочее-прочее.

Тем плохо, что кол-во экземпляров этих классов будет равно кол-ву открытых соединений с БД. Плюсом экземпляры класса могут умереть неожиданно, а соединения будут висеть не закрытыми, что не очень хорошо.
Нужно стремиться к тому, чтобы было минимальное кол-во соединений с бд.
Denis Derepko дал правильное направление тебе.

Можешь попробовать приводить все входящие данные url к одному виду(canonical) и хранить этот вид в базе в отдельной колонке.
Допустим, сперва определяешь сколько уровней домена.
ecco.ru - 2 уровня (ecco и ru),
men.ecco.ru - 3 (men, ecco, ru),
www.men.ecco.ru - 4 (www, men, ecco, ru)
Сделать это можно как-то так:

$urls = "www.ecco-shoes.ru
www.ecco-shoes.ru
http://ecco-shoes.ru
https://www.ecco-shoes.ru/
www.ecco-shoes.ru/
ecco-shoes.ru
www.ecco-shoes.ru/?
www.ecco-shoes.ru/#
www.ecco-shoes.ru/index.php";

$urls = explode("\n", $urls);

foreach ($urls as $url) {
	$hostname = parse_url($url, PHP_URL_HOST);
	$domains = explode('.', $hostname);
	
	echo $url."<br/>";
	echo $hostname."<br/>";
	
	foreach ($domains as $domain) {
		echo $domain."<br/>";
	}
	
	echo "<br/><br/>";
}

Затем конструируешь из этих частей урла нужный вид, например игнорируя www, и сохраняешь это в базе в доп. колонке. Желательно все эти части привести к одному регистру, допустим к нижнему.

И всё, затем проверяешь был ли уже такой урл простым запросом в бд по колонке с каноничным урлом.

Пишу самописный движок одного сайта.

Не буду даже объяснять насколько нелепа затея.
Просто несколько вопросов, которые Вам лучше самому себе задать и ответить:

• С какими цмс и фреймворками Вы уже работали и насколько глубоко их знаете ?
  
• С каким кол-вом проектов в целом уже сталкивались, какие сложности возникали ?
  
• На какой тип проектов рассчитана Ваша cms ?
  
• Какие готовые решения будете брать за основу ?
  

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

Какой htaccess ? А если "сайт взлетит" и придется nginx поставить ? :) Ладно, шучу, не взлетит ни сайт, ни cms, так что за это не беспокойтесь :)

По сути Вашего вопроса.
У Вас должен быть слой, который отвечает за сопоставление запроса к некоторому контроллеру/действию/методу/еще чему-то. Назовем данный слой Router.
А у Router'a может быть такая логика: если после домена идёт /(ru|en|pl), то установить в сессию или куку соответсвующее значение текущего языка.
В коде, где выводите какой-либо текст, то оборачиваете этот текст в метод перевода. Например, пусть это будет статический метод Translator::trans($message). Внутри статического метода берёте из сессии/куки текущий язык и смотрите есть ли данное сообщение для такого языка. Ну а дальше развивайте логику, как хотите.

$sourceArray = *предполагаю, что извлекли все записи из базы*;
$newArray = [];
foreach ($sourceArray as $el) {
    if ($el['parent_id']) {
        $newArray[$el['parent_id']]['children'] = [
            'id' => $el['id'],
            'text'=>$el['text'],
            ...
        ];
    } else {
        $newArray[$el['id']] = [
            'id' => $el['id'],
            'text'=>$el['text'],
            ...
        ];
    }
}

подойдет ?

Настройка компонентов веб-сервера, а именно - сам веб-сервер(я выбрал давно и не пожалел nginx), php-fpm, mysql - настраивается точно также, как на любом линуксе(убунта, центос и т.д.).
Мне понравился вот этот пакетный менеджер для мака. По ссылке есть, как его установить. Дальше через него всё ставим.
Стал писать мануал, но вот набрел на статью.
Будут вопросы, спрашивай.

Попробуйте
list(, $key, $value) = explode("=", $explode[0]);

Если есть доступ к исходнику, то подделать можно что угодно. Можете посмотреть в сторону обфускации, но это всё ровно не надежно будет.
Если нужно быть уверенным, что ничего в скрипте не менялось, то я вижу только 1 вариант.
Сам файл index.php должен просто перенаправлять запрос к Вам на скрипт по апи со всеми данными, вы обрабатываете их у себя и отвечаете скрипту index.php, index.php передает ответ от Вас пользователю.
Простым языком файл index.php, который может любой скачать и к себе установить должен в этом случае являться просто прокси к Вашему API.

Роботс закрывает от индексации. В вашем случае лучше будет использовать sitemap.
А если по-хорошему, то весь ajax привязывайте к урлам. Идеальный вариант, который я стараюсь соблюдать последние пару лет, это когда при клике на ссылку меняется урл в браузере, но данные обновляются через ajax. Если по этой ссылке перейти, то отображается та же страница, что и подгруженная аяксом. Иными словами при клике на ссылку не должно быть разницы сработает js(ajax) или просто перейдем по ссылке.