VisualIdeas

1. Централизованной админке ничто не мешает быть реплицированной копией на всех серверах.
2. Доступ к каждому серверу из центр. админки осуществляется с помощью двух факторов:
2.1. Авторизация веб-клиента в админке (получение токена1)
2.2. Аутентификация веб-клиента на сервере через API (получение токена2; сервер также сообщает его хеш админке напрямую)

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

Данные (файлы фронта и сам php-скрипт) - также можно реплицировать и управлять этим через ту же админку.
Базу - никто не мешает Вам вынести на отдельный сервер и создать к ней RESTful API, через которое можно будет обращаться с любой площадки из своих скриптов. А там уже: и шифрование трафика, и защита данных.
И, разумеется, не забыть создать кеш-систему для RESTful API от центральной БД на каждой площадке (Redis - уже не подойдёт, т.к. тут не прямой коннект, а RESTful..).

Админку можно разместить рядом с БД (на одном сервере/хостинге), НО! под другим аккаунтом, т.к. доступ к базе - она будет получать всё равно через RESTful API с токеном площадки, поэтому, риска доступа к БД со стороны (кроме работников самого хостера!) - никаких нет.

Сделайте синхронизацию БД, все будет супер быстро и «в одном месте» в случае обвала бд да беда, но можно на репликах продержаться, как я понимаю вещи которые нужны в одном месте это учетки и биллинг?

Один из вариантов - разнести сайты по разным хостам (или контейнерам), а админку - на отдельный сервер, с доступом только через VPN.

Отдельный сервер с БД и несколько серверов с сайтами

Если для каждого сайта использовать свои credentials с доступом только к "своей" базе, то этой проблемы нет.

Но в виду некоторых вещей мне необходимо чтобы бОльшая часть данных была централизованно в 1 месте и вариант иметь централизованную админку которая по АПИ дергает каждый сайт и управляет контентом.

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

Имхо, бесполезная метрика. Давайте разберёмся почему.
Что нам даст данная метрика? Ничего. Бизнес-логика и сетевые издержки съедают куда больше и на их фоне производительность движка даже не заметна. А если вспомнить что проект состоит не только из кода так вообще смешно становится

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

1) Оно мегахреново переносится и очень криво становится на свежие системы. Корме того что половина гайдов по установке устарела, но все еще лежит на оф. сайте, гайды сообщества противоречат друг-другу, 90% из них не работает, а про некоторые дистрибутивы можете просто забыть, там они работать просто не будут.

2) Оно все работает as is и хрен ты посмотришь как работает родная вьюшка/конторллер "внутри", а доки не сказать чтобы хорошо описаны, комьюнити слабенькое, многие вещи сделаны спорно, а поправить или что-то подкрутить дело неблагодарное.

3) Теперь про самое интересное - скорость работы. Так вот, вся это мутотень про память и прочие плюшки на нормальном сервере не ощущается вообще, то есть переходя определенный предел мощности/вооруженности сервера скорость практически сравнялась с нативом (использовался ларавел и Уии на том же сервере, по замерам - плюс-минус то же по скорости, и чуть больше по памяти (центос, 64гб оперативы, 4 проца, нжинкс, пхп 7.2). Короче выгода была на ветке пхп 5.+, сейчас его актуальность практически равна нулю.

4) В моем случае по приходу сервер регулярно падал при "серьезной" нагрузке (20-30рпс), в чем я изначально предположил вину старых модулей фалкона, но по факту оказалось что 99% нагрузки вносили ожидания запросов к бд, некоторые из которых были по 7-15 минут, а некоторые куски кода создавали по 80+ запросов с 1 страницы, просто дозапрашивая какие-то данные для вьюшки в цикле. Предыдущий "кудесник" кормил руководство отмазками типа - "мало памяти, железо слабое, все плохо, а то бы летало...". "Магия плохого железа" закончилась после оптимизации запросов и доведения самых тяжелых до 0,5 секунды, а так же выборки всех данных в 1-2 запроса с нормальными джоинами.

5) Основной вопрос всегда сводится к жадности - взять что-то побыстрее из софта, сэкономив на хостинге/оборудовании. И оно всегда не работает так, по ряду факторов, которые достаточно очевидны.

Соберите проект на 2х фреймворках и сравните. Кроме скорости еще надо принять во внимание удобство и затраченное время.

Думаю перейти на Symfony или Laravel (ибо делаю сайты для клиентов и поддерживать сайты иногда приходится уже другим людям и разбираться в чуом коде для них не самое простое дело - хотябы по затратам времени)

Laravel. Без вариантов.

С точки зрения производительности для "сайтегов" подойдёт почти любой фреймворк, узким местом действительно станет бд, но про грамотных запросах и индексах держать нагрузку будет.

До знакомства с magento2 мог сказать что вообще любой бери и юзай, но теперь, к сожалению, говорю почти любой

Глупый вопрос на самом деле:

Сейчас в пхп-мире среди фреймворков есть да выбора (Symfony/Laravel) - первый выбирают ребята покрупнее, второй выбират ребята поменьше. Есть еще Zend Framework но так в качестве поддержке легаси систем.

Так вот: скорость работы фреймворка - бессмысленный показатель. Ибо пока идет малая нагрузка - всем плевать. Когда нагрузка подрастает - докупают железо. Если железа получается уже очень много - то делают перфоманс анализ и правки. Если уже совсем все плохо, переписывают на Go. Смотри доклады ребят на php-конференциях от Баду, Авито и так далее.

Но все эти шаги делает максимум 1% от всех компаний, что юзает эти фреймворки, ибо 99% никогда не столкнется с такими нагрузками.

__

Ты лучше смотри так:

Symfony - Москва - зп мидла 140к плюс.
Laravel - Москва - зп мидла 120к плюс.
1С-Битрикс - Москва - зп мидла 80к плюс.

Собственно, как в фильме "Невероятное приключение Итальянцев в России" - Андрюша, ты хочешь заработать миллион?

Есть есть возможность выучить Symfony и лутать 140к, зачем учить условный phalconPhp и лутать 60-80к?

Поднимать что-то в зоне dev плохая идея.
Это существующая зона с политикой https-only. https://ma.ttias.be/chrome-force-dev-domains-https...
Так что либо создавайте сертификаты, либо выберите другую зону.

Upd: собственно я на 99.99% уверен, что домен они видят, но пытаются соединиться по https, а у вас его скорее всего нет.

По аглицки читаете? Вот народ тестировал, и обсуждал.
https://forums.docker.com/t/mysql-slow-performance...

Эта прослойка называется Cgroups и по идее, она не должна мешать вообще, так как работающие нативно программы также работают через данную прослойку, только с другими политиками. Есть одно исключение - сетевые интерфейсы, они обычно работают тоже нативно, но иногда заводятся в виртуальный бридж (коммутатор), тут есть накладные расходы на дополнительный просмотр заголовков и тегов пакета. Но обычно всем этим можно просто пренебречь и заявить, что скорость работы программ в docker/lxc/cgroups практически ничем не отличается от скорости нативных приложений.
Другое исключение, если используем виртуализацию с аппаратным управлением (KVM), тут в зависимости от конфигурации можем проиграть от 1.5 до 10%.

Text в InnoDB, как помню, лежит отдельно от самой строки (в отличие от varchar), так что можно подумать над выбором типа для оптимизации производительности. Базка при этом может вырасти в размере. Движок менять определённо смысла нет.

А разве MyISAM вообще повзволяет делать фрагментированные таблицы? По моему эта функциональность есть только в инно-дб, так что ты к типу уже привязан.

По теме: даже если будет быстрее, то на какие-то доли процента (но да, разница если и будет то в сторону убыстрения). Но овчинка выделки не стоит.

Имеет смысл оставить на InnoDB и указать сжатие таблицы с ROW_FORMAT=COMPRESSED и поэкспериментировать с размером ключа для выяснения с каким получится компактнее. Будет необходимо перенести данные из старой таблицы при помощи
Insert into ... select from ...

1. Добавить в конец строки запроса: LIMIT 1
2. Повторный предыдущий "запрос" (только вывод результатов, он не ищет уже!) без лимита: SELECT FOUND_ROWS();
3. Можете ДОПОЛНИТЕЛЬНО создать пару своих таблиц: уникальные слова (id, слово) и линковки к записям (id-слова, id-записи в большой общей таблице) - это указатель для связок уникальных слов к ID-шникам записей исходной (большой) таблицы.
4. Поставить всё на скоростной SSD (и настроить производительность БД).

Всё остальное - прироста скорости никак не даст.
PS: Сверх-сложный вариант: полностью создать свой DAG.

Зависит от проекта, поэтому нужно пробовать разные варианты и измерять. Готового рецепта нет.
Я делал на эту тему доклад в разрезе HTTP/2: https://www.youtube.com/watch?v=rQDd5kCwDj8 Но там и в принципе про лучшие практики фронтенда много всего полезного.
В презентации куча ссылок.