smilingcheater

Если у вас задача потребляет CPU по максимуму, то да - распараллеливать её на большее количество процессов, чем имеется в наличии потоков - бессмысленно.
Но обычно задача по добавлению записи в БД потребляет не слишком много поцессора. А если речь про "парсинг", где процессор 99% времени ждет пакет из сети, распараллеливать можно хоть на десятки процессов.
Конкретное количество зависит от потребления процессора конкретной задачей.

Количество потоков не всегда равно количеству ядер, умноженному на два. Надо смотреть на конкретный процессор. Тем более на VPS, где процессор тоже виртуальный.

Если говорить про конкретный пример, то в идеале конечно надо написать нормальный код, который запишет в БД несчастные 3 тыщи товаров меньше чем за секунду. А заниматься параллелизмом уже когда счет пойдет на сотни тысяч. Тем более что цифра скорее всего взята с потолка. Я много повидал говнокода на своем веку, но такой, чтобы добавление одного товара занимало 30 секунд я даже вообразить себе не могу.

Единственная загадка - при чем тут "web", если речь идет про CLI. И, если уж говорить про веб, то с какой радости он "однопоточный".

Нет такого понятия "вытянуть видеокарту".
Если процессорной производительности будет недостаточно, то простаивать будет и 4090 и 1030.

Для большей части современных игр достаточно производительности современного i3 процессора.
12600K - это сильно с запасом. Скорее всего, нагрузка в играх на процессор будет не более 50%, разумеется, при адекватной утилизации мощности видеокарты.

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

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 для фестиваля"