d'Ivan

1. Оптимизация SQL запросов.
2. Кеширование часто используемых данных.
3. Кеширование ответов на GET запросы.

все упирается в бд, на ум сразу пришло вынести эту часть в микросервис

Какой ещё микросервис? Микросервис, который делает что?

В-нулевых, нужно конкретизировать что значит "упирается в БД". Тормозят какие-то конкретные запросы? СУБД не хватает ресурсов? Слишком медленный диск? Или, может, под "упирается в БД" вы понимаете всю бизнес-логику приложения, которую вы называете "берет из бд нужные данные" (и тогда становится понятно про микросервис)?
Во-первых, нужно вынести СУБД на отдельную машину, желательно на голое железо (если речь про реальный хайлоад, а не про кривой код и конфиги).
В-третьих, под это железо нужно СУБД корректно сконфигурировать.
В-четвёртых, нужно добавить кэширование.
В-пятых, нужно проверить алгоритмы и пофиксить узкие места (на последнем месте, потому что это самое трудоёмкое).

Я понимаю, что python и django не самые быстрые инструменты (мягко скажем)

Я вас уверяю, что проблема в вашей компетенции (мягко скажем), а не в инструментах. Есть достаточно проектов, написанных на Джанго, которые вывозят большие нагрузки.
Вы, в принципе, правильно сделали, что попытались поначалу закидать проблему железом - оно обычно дешевле, чем время разработчиков. Но параллельно надо и оптимизацией заниматься, и это требует системности, которой в вопросе не очень-то видно. Ну и компетенций разных - если тормозят алгоритмы - это одно, если конкретные SQL-запросы - это другое, если СУБД задыхается в принципе - это третье.

Запустил профилировщик, увидел, что все упирается в бд, на ум сразу пришло вынести эту часть в микросервис,

Начал правильно, но вывод сделал левый, по уму надо начать с тюнинга postgresql, оптимизировать SQL запросов (может у тебя там индексов не хватает или еще хуже, проблема N + 1), кешировании данных.

На 146% уверен что это BOM.
Надо пересохранить файл из какого-нибудь текстового редактора или научить 1С не добавлять BOM.

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

4pda основан на ip.board, все загружается без танцев с бубном, только осторожно, без авторизации получаются другие страницы чуть в ином формате. Вот пример кода на основе simple_html_dom:

<?php
include('simple_html_dom.php');

// ссылка на первую страницу темы
define('START_URL','https://4pda.to/forum/index.php?showtopic=1084129');
// количество страниц &st= из ссылки » в навигаторе по страницам
define('PAGES_CNT',580);

@mkdir('data');

for($i=0;$i<=PAGES_CNT;$i+=20)
{
	// формируем url
	$url=START_URL.($i==0?'':'&st='.$i);
	// имя кеш файла чтобы не загружать повторно
	$cache_fn='data/'.md5(START_URL).'.'.$i.'.html';
	if(!file_exists($cache_fn))
	{
		// Загружаем страницу
		$data=file_get_contents($url);
		// сохраняем страницу в кеше
		file_put_contents($cache_fn,$data);
		// пауза между запросами к серверу для защиты его от ddos
		sleep(1);
	} else
	{
		// читаем из кеша
		$data=file_get_contents($cache_fn);
	}

	$html=str_get_html($data);
	$num=0;
	foreach($html->find('div[class]:not([class=""]') as $post)
	{ // перебираем посты в теме
		// пропускаем первый пост темы, он дублируется на каждой странице
		if($num++==0) continue;
		// выводим пост на экран
		$post_html=$post->find('div.post_body',0)->text();
		echo $post_html.PHP_EOL;
	}
	// вставляем разделитель между постами
	echo '<hr/>'.PHP_EOL;
	$html->clear();
}
?>

вернет на экран посты указанные в START_URL, мне лень было вычислять конец треда автоматически, бери количество постов вручную из навигатора постов.

Страницы можешь вручную указать for($i=0;$i<=PAGES_CNT;$i+=20) вместо 0 - начальный (с шагом 20) и PAGES_CNT конечный пост.

Вместо текстового представления $post_html=$post->find('div.post_body',0)->text(); можешь сложнее структуру сообщения анализировать, выявляя цитирования и к примеру исключая их из текста (они занимают большую часть всего, дублируя многократно информацию).

Конкретно этот пример не влезет в контекстное окно бесплатного claude - это 70к токенов. Поэтому дели на куски.

2 < 10
'2' > '10'
Непправильный тип поля place.

Delphi так и просится по всем пунктам. Бесплатной Community Edition хватит вполне.

В общем, почитав англоязычные форумы, то что я называл "странным" явлением, считается скомпрометированным сервером. Редис сервер был ничем не защищен и подвергся атаке(буквально в течении полу часа после раската). Единственное решение этого вопроса является защита, а именно необходимо установить юзера/пароль и сменить порты. Все это помогло мне в моей проблеме. Мораль сей басни такова, необходимо делать сразу защищенный доступ и будет вам счастье!