Max Payne

В общем, на сколько я понял, память у меня и не текла.

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

Таким образом получалось, что страницы поиска парсились быстрее, чем генерировались айтемы на основании записей с них, создавалась длинная очередь и память переполнялось. Помогла установка значения DEPTH_PRIORITY = 1.
Однако скорость парсинга, к сожалению, снизилась.
Старт двух спайдеров в двух разных процессах немного улучшил ситуацию.

У VK CallBack Endpoint'a нельзя указать порт, то есть все запросы будут идти на 80-й в любом случае. Дальше на своем сервере можете проксировать куда угодно.

Во-первых, почитайте про vk callback api. На основе асинхронного веб-сервера типа aiohttp или tornado будет очень быстро.
Во-вторых, на сколько я понял, вы хотели использовать список вместо очереди. Не нужно. Если уж использовать, то хотя бы queue.Queue.
В-третьих, первый вариант явно провальный, будет работать не очень круто, если даже заставите хоть как-то работать. Второй вариант выглядит более логичным, если всё таки решите использовать лонгпулл, но здесь без многоточности/многопроцессорности, думаю, не обойтись.

В итоге: если делать через лонгпулл самый простой вариант - один процесс/поток с бесконечным циклом, который делает await session.get(longpoll_url).json(), далее ЛИБО добавляет задания в очередь для хендлера, который работает во втором процессе с таким же бесконечным циклом, ЛИБО порождает новый поток/процесс для каждого нового сообщения. Но здесь сразу же, даже до этапа проектирования, видно много узких мест. Если делать через колбек - узких мест, фактически, нет. Например, многопроцессорный асинхронный торнадо (но уступающий в однопотоке по-умолчанию асинхронному aiohttp), справится с любой нагрузкой, узких мест нет, он, по сути, сам в своих потоках/процессах будет разгребать новые запросы, вам об этом думать будет не надо.

Предыдущий агрессивно-бесполезный оратор удалил свой ответ порекомендовав мне, как очень умному, ответить за него:

Сервисы ВКонтакте - не что иное, как новомодные VK Apps.
BackEnd для них можете написать на чём угодно, хоть на python, хоть на PHP, хоть на node.js. НО, вас скорее интересует как делать такие же интересные одностраничные приложения, как в примерах по первой ссылке? Так вот, альтернатив Javascript'у в FrontEnd попросту нет.
Поэтому только с использованием Python и его фреймворков что-то сделать да можно, но вы ведь понимаете, что таким образом у вас фактически будет отсутствовать вменяемый фронтенд, а подобные приложения ориентированы в первую очередь на удобство для пользователей, красоту и одностраничность - когда передвижение по нему выполняется без перезагрузки. Без фронтенда так не получится, а фронтенд - это javascript.

How to get a token and channel ID for Discord

p.join() в данном случае сработал, но это не даёт понимания почему трейсбеки не возвращаются :(

Проблема оказалась в сбое выгрузки кода на сервер. То ли там была старая версия main.py без условного ClassB, то ли старая версия __init__.py или ещё что-то. Решилось повторной принудительной загрузкой этого плагина.
Не догадался бы, если не поизменял файл __init__.py по подсказке Zanak ;)

Нашёл для себя такое решение.

class Chat:
    def __init__(self, bot, i=0):
        self._bot = bot

        data = modules.Chat.objects(bot=bot.id, i=i)

        if not data:
            self._data = modules.Chat(bot=bot.id, i=i).save()
        else:
            self._data = data[0]

    def __getattr__(self, item):
        self._data.reload()
        return getattr(self._data, item)

    def __setattr__(self, key, value):
        if key not in ('_data', '_bot'):
            data = self._data.__setattr__(key, value)
            self._data.save()
            return data
        else:
            return super().__setattr__(key, value)

Но осталась проблемка: когда поле является EmbeddedDocumentListField - в него нельзя сделать append / extend / pop и тд.

В своих проектах я использую отдельный процесс для этого, который из базы данных получает данные о задачах на текущую минуту. Запускает их многопоточно (multiprocessing.pool.ThreadPool), либо можно и многопроцессорно (multiprocessing.Pool), в зависимости от задачи, и дальше "спит" 60 секунд.

Ознакомьтесь с документацией

Передайте файлы на адрес upload_url, полученный в предыдущем пункте, сформировав POST-запрос с полями file1-file5

json.dumps(KEYBOARD_STEP_1, ensure_ascii=False).encode("utf-8")

f = lambda data: data.count(True) >= len(data)/2

words = ("car", "end")
print(list_symbol[:list_symbol.find(words[0]) + len(words[0])] + list_symbol[list_symbol.rfind(words[1]):])

UPD. Прогнал по 1 000 000 раз тесты своего варианта, и варианта Юрий - разница оказалась меньше, чем я думал. В среднем на тестовой машине: 9.2 * 10^-3 мс у варианта Юрий и 7.6*10^-3 мс у моего варианта.

Добавьте в sys.path путь до src, в ином случае Python видит только директорию в которой он запущен + все директории, находящиеся внутри текущей, а так же директорию самого Python.

Проблема оказалась в том, что для каждого процесса создаётся своя копия класса.
Есть два решения:
1. Заменить multiprocessing на threading (нет)
2. Использовать что-нибудь, что позволяет передавать информацию между процессами, например multiprocessing.Value (Sharing state between processes)