smilingcheater

Давайте отделим мух от котлет и пофилософствуем на тему трансцендентного понятия "вытянет"... :)

1) Для начала поймем, что процессор и видеокарта выполняют разные операции. Процессор готовит материал, а карта визуализирует. Соответственно нагрузка на процессор растет с частотой кадров видеокарты, но рост этот недетерминирован, меняется от места в игре, от настроек графики, от игры к игре, от количества игроков и т.д.
Оттуда мудрость - чем мощнее видеокарта тем выше вероятность, что процессор начнет упираться. Но когда это наступит и где? Кому ведомо?

2) Далее надо отметить, что не все движки игр реально многоядерные. Есть такие ситуации, где задачи не делятся между ядрами. Ну не всегда 9 женщин могут выносить одного ребенка за 1 месяц.
Оттуда мудрость - чем выше частота одного ядра, тем иногда это полезнее, чем количество ядер. И есть задачи, где i3 будет быстрее, чем i5 за ту же цену.

3) Иногда процессор или видеокарту покупают по тем же причинам, по которым берут большие черные джипы (своего рода "членоудлиннитель").
Оттуда мудрость - иногда надо брать 4090 и процессор 10400, не для того чтобы играть, а для того, чтобы ПОКАЗЫВАТЬ. Ибо денег на что-то одно, а чувство собственной важности лучше растет от указанной связки, чем от чего-то типа i9 13900k + GTX1050.

4) Умудренные опытом люди, давно, успешно и много раз пережившие "апгрейдные лихорадки" - становятся меркантильны и прагматичны. Они даже не меряются ФПС (вот с i7 - их, допустим, всего 175, а с i9 - аж 184!). Они понимают, что ИХ глаза столько не видят. Они сидят на мониках 60-75 Гц и не парятся.
И например их игровая прелесть, Хогвардс там какой, или Фаллаут очередной - прекрасно идут на 10-м поколении интел и старом RTX 2070 в FullHD и на 60 Гц, и далее нефиг тратить деньги.
Оттуда мудрость - какая разница, что кого потянет, есть оптимальное соотношение "общая цена"/"производительность" под конкретную задачу. Какая разница, что длиннее в попугаях - 175 ФПС или 185, если на мониторе выставлено 75?

"...- Палубной команде - ставить трал!
- Поставить можно клизму. Трал отдают... " (С) Ю. Иванов "История пропавшего корабля"

Так вот, натянуть можно подружку. Или кепку на уши. А страницу загружают посредством FTP-клиента при наличии логина и пароля, который должен выдать провайдер.

т.к. красные не могут.

А во что конкретно не могут по твоему мнению?
Есть обратный принцип nvidea не может и есть обоснование во что оно не может например не может написать драйвера под линукс или хотябы дать сорсы драйверов под их разработку так как контракт с майками не позволяет

На что деньги есть, то и берите. Нет там каких-то требований к железу. Там больше про умение думать и анализировать.

Хранить html код в столбце поста кажется нецелесообразным по ряду причин:

Угу, ага...

Лишняя трата памяти на хранение html тегов

Ого, а лишние это сколько? Экономия на байтах чаще всего приводит к тратам на вычислительные мощности. Некоторые расчеты чуть ниже.

Уменьшение производительности (?)

Производительности чего?

Стили/компоненты могут изменяться, а код останется прежним

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

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

Ага, переизобретаем BBCode, найс... Для понимания проблемы - такие коды придуманы для форумов, с целью ограничить использование хтмл в пользовательском вводе. При этом подходе он худо-бедно оправдан, хотя и требует постобработки при каждом выводе, а это использование регулярок, что как бы совсем не бесплатно. В вашем же случае, источник текста более-менее доверенный, и ограничение в тегах больше мешает чем помогает.
Что касается экономии на "минифицированных" тегах, ну допустим сэкономите вы 100 байт на тегах, то есть на 1000 постов экономия будет.... ТА-ДАААМ! 0,1 мегабайта! А если экономия 1000 байт на пост, то целый МЕГАБАЙТ можно сэкономить! Похвальная рачительность.

Хранить каждый элемент поста отдельно в бд со следующим содержанием (element_name, position, content, post_id), используя отношения к родительскому посту, соответственно сохранится структура и рендериться пост будет через соответствующие компоненты в нужном порядке (однако как будет именно рендериться в шаблоне поста пока неизвестно)

Базовые элементы и так должны храниться отдельно, другой вопрос почему они у вас рендерятся в одном порядке, а в другом месте в другом порядке? Заголовок, короткое описание, текст, главное изображение - отдельные поля, оглавление по сути часть текста, зачем его выносить отдельно - загадка, это же такой же текст, котрый автор волен располагать . Вариант с внешней таблицей по сути приводит нас к выносу части данных в EAV(отличный пример универсализации в ущерб производительности), что как раз будет серьезно напрягать выборки бд, если понадобится делать какие-либо поисково-выборочные манипуляции по этим данным.

Правильно - идти к профессионалам, которые будут гарантии связи по ТТХ давать.
Они разворачивают сеть из специализированных точек доступа с mesh сетью и контроллерами.

А вообще предполагаю, что вопрос отвечается простым гуглением типа "wifi для фестиваля"

Обычная настройка разгона:
1. ставим желаемую частоту процессора и максимально приемлемое напряжение и сразу проверяем. Если тест стабильности не проходит, уменьшаем хотелки.
2. понижаем напряжение с контролем стабильности.
3. чуть чуть понижаем частоту и поднимаем напряжение, что бы не было сюрпризов.
4. выставляем желаемую частоту памяти и максимально приемлемое напряжение, расслабляем тайминги от души. Понижаем частоту если не заводится.
5. понижаем тайминги (не забываем про постоянные тесты)
6. пытаемся понизить напряжение. Делаем небольшое повышение после нахождение минимума.

Спустя несколько дней перезагрузок радуемся приросту производительности в играх в зоне погрешности измерений, так как упор шел в видеокарту. И еще неделю спустя после внезапных сбоев возвращаемся на стоковые настройки.

Не надо ничего выдумывать с виртуалками. LEMP прекрасно изолируется и конфигурируется на уровне пользователя и php-fpm pool. Если требуются какие-то дополнительные ограничения, то есть Cgroup и Disk Quota.