Asyncio + PySide6 + Telethon: список чатов и треды грузятся 30 минут — где искать причину?

Question

[Наталия]

Делаю десктопное приложение на Python (PySide6 + Telethon + SQLite) для парсинга Telegram-чатов. Проект в открытом доступе:
github.com/Nynchezyabka/RozittaParser

Сразу честно: я не программист, проект создан в формате вайбкодинга потому что сначала была одна задача на консольный скрипт, а потом я просто не смогла остановиться. Поэтому буду очень благодарна за объяснения простым языком — я понимаю что происходит в программе, но не всегда понимаю почему и как это починить. А сейчас прямо очень нужно это всё в связи с текущим положением дел.

Столкнулась с двумя проблемами и не могу понять — это мой баг или внешние ограничения Telegram API.

**Проблема 1: список чатов загружается ~30 минут**
Используется GetDialogs через Telethon. При этом отдельный консольный скрипт с той же логикой работает значительно быстрее.
Подозреваю что проблема в том как asyncio event loop взаимодействует с потоком PySide6 — но не уверена.

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

16:23:38 — начало (total_est=47998 сообщений)
16:24:28 — 100 сообщений
16:27:39 — 200 сообщений
...
20:07:53 — 12400 сообщений (всё ещё идёт)

То есть ~100 сообщений в среднем за 2-5 минут.
Без единого медиафайла, только текст.
Это нормальная скорость для Telethon или что-то явно не так?

**Проблема 2: database is locked**
SQLite, WAL-режим включён, thread-local соединения реализованы,batch insert настроен (по идее). Ошибка всё равно периодически появляется при одновременной работе нескольких воркеров (Parse → STT → Export).

**Архитектура:**
- asyncio event loop живёт в отдельном потоке
- GUI в основном потоке Qt
- общение через Qt-сигналы
- каждый воркер создаёт собственный TelegramClient

Comments

[Adamos]

Этой проблеме меньше трех дней? А сам Телеграм вы за это время запускать не пробовали?..

[Наталия]

Adamos, проблеме больше трёх дней, нормально грузились списки чатов только когда это приложение было консольным скриптом, а это было наверное пару месяцев назад. Телеграм у меня работает через те же самые пути обхода, один впн на всё. да, он медленно грузит файлы, но загрузить список чатов или веток в группе проблемы нет. Возможно это из-за того что новые сессии каждый раз и оно разгонится со временем, не знаю. Сейчас стало совсем тяжело понять — это мой баг или внешние помехи.

Answer 1

[Наталия]

Вопрос решен с помощью прокси и кэша)

Answer 2

[Андрей Прохоренко]

https://github.com/eminsk/RozittaParser
все правки то что считал сделал там если какие вопросы пиши уже в моем репозитарии уже
если какие будут вопросы.

Резузультаты теста
uv run pytest
============================= test session starts =============================
platform win32 -- Python 3.14.3, pytest-9.0.2, pluggy-1.6.0
rootdir: C:\proekts\RozittaParser
configfile: pyproject.toml
collected 86 items
tests\test_core\test_database.py .................. [ 20%]
tests\test_core\test_merger.py ............ [ 34%]
tests\test_core\test_utils.py .............................. [ 69%]
tests\test_features\test_export.py ........... [ 82%]

Я разобрал код, и у тебя тут не одна причина, а несколько конкретных узких мест.
Главное: это не “просто Telethon медленный”. В проекте есть реальные места, которые сами создают тормоза и database is locked.
Что у тебя тормозит на самом деле
- Список чатов тормозит не столько из-за get_dialogs(), сколько из-за доп. запросов после него: в features/chats/chats_api.py:183 список диалогов грузится один раз, но потом в features/chats/chats_api.py:229 для каждого канала идет GetFullChannelRequest, чтобы проверить linked group. Если каналов много, это уже пачка сетевых запросов.
- Топики форума могут резко тормозить, если прямой API не срабатывает и код уходит в fallback-скан сообщений: features/chats/chats_api.py:381. Это уже не “получить список веток”, а “пройтись по сообщениям и угадать ветки”.
- Текстовый парсинг у тебя явно ненормально медленный. Самая сильная причина, которую я вижу: очень агрессивное логирование. В features/parser/api.py:826 есть debug-лог практически на каждое сообщение, а в core/logger.py:124 и core/logger.py:197 файл-лог включен на DEBUG вообще для всего приложения. На больших чатах это легко убивает скорость.
- В features/parser/api.py:530 ты вызываешь iter_messages(...) без wait_time. У Telethon на больших историях это часто добавляет внутренние паузы между запросами. Это не объясняет 4 часа целиком, но добавляет тормоз.
- Еще один баг: по документации ты рассчитываешь на batch insert, но фактически во время основного прохода строки копятся в памяти и пишутся в БД только в самом конце: features/parser/api.py:387, features/parser/api.py:416. То есть во время “долгого парсинга текста” тормозит не SQLite, а сеть/логирование/итерация.
Откуда берется database is locked
Тут у тебя, похоже, смешиваются две разные блокировки.
- Telethon session — это тоже SQLite. Если одновременно живы два TelegramClient на одном .session, получаешь тот же database is locked.
- Архивная БД сообщений — отдельная SQLite, и она тоже может ловить lock.
Самый опасный кусок у тебя тут: ui/main_window.py:1590.
- Перед стартом ParseWorker окно ждет ChatsWorker и TopicsWorker только 30_000 мс.
- Если загрузка чатов реально висит дольше, ты все равно потом стартуешь парсер: ui/main_window.py:1606.
- Это значит, что ChatsWorker еще может держать Telethon session, а ParseWorker уже открывает новый TelegramClient.
Это очень похоже на главный источник твоего периодического database is locked.
То есть проблема не “SQLite плохой”, а “два клиента пересеклись по времени на одном session-файле”.
Что я считаю корнем проблемы по приоритету
1. Слишком подробный DEBUG-лог в файл на больших объемах — core/logger.py:124, core/logger.py:197, features/parser/api.py:826.
2. Старт ParseWorker, пока ChatsWorker/TopicsWorker еще не закончили — ui/main_window.py:1590.
3. Дорогие дополнительные запросы для linked group после get_dialogs() — features/chats/chats_api.py:229.
4. Возможный fallback-скан топиков вместо прямого API — features/chats/chats_api.py:381.
5. Batch insert реализован не так, как ожидается: запись откладывается до конца — features/parser/api.py:416.
Почему твои цифры выглядят подозрительно
- 48k текстовых сообщений за почти 4 часа — это слишком медленно.
- Даже если Telegram иногда душит историю, это не должно быть настолько плохо на чистом тексте.
- Значит, почти наверняка тормозит не только Telegram API, а еще и твоя обвязка вокруг него.
Что я бы исправлял первым делом
- Временно понизить файловый лог с DEBUG до INFO и убрать per-message debug-лог.
- Не запускать ParseWorker, если ChatsWorker или TopicsWorker еще живы. Не “подождать 30 секунд”, а именно не запускать вообще до полного завершения.
- В iter_messages(...) явно задать wait_time=0 или маленькое значение и заново замерить.
- Кэшировать linked-group данные, чтобы не делать GetFullChannelRequest для каждого канала каждый раз.
- Писать batch в БД периодически по ходу парсинга, а не только в конце.
- Добавить retry на lock в insert_messages_batch() и upsert_messages_batch() в core/database.py:351 и core/database.py:402.

Comments

[Everything_is_bad]

Я разобрал код

не ты, а LLM

[Андрей Прохоренко]

Everything_is_bad, LLM не будет делать тесты и выкладывать на гит и проверять все моменты и нюансы
и все тестировал сам с помощью uv

[Telcontar]

Андрей Прохоренко, будет. Claude Code называется

[Андрей Прохоренко]

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

[dim5x]

А вы запускали код?)

[Everything_is_bad]

Андрей Прохоренко, твой ответ сильно шаблонный как обычно выдает LLM

все тестировал сам с помощью uv

это как? и при чем тут uv, он для разруливания зависимостей и запуска инструмента тестирования pytest. Ты тестируешь с помощью pytest.

[Алексей Уколов]

Everything_is_bad, вот же написано "uv test". Шах и мат!

[Алексей Уколов]

Андрей Прохоренко, если вы нас за дураков держите, так держите правильно!

[maksam07]

Алексей Уколов, Алексей Уколов, не менее удивительно, что вопрос был задан пол дня начал, а автор уже сделал форк и новый коммит: 63 files changed
+21450
-0
lines changed

Его скорость работы удивляет xd

[Андрей Прохоренко]

dim5x, конечно и все запускается и тесты все проходят

[dim5x]

Андрей Прохоренко, прикольно. А то что в ui.py импорт поломан из-за чего загрузка чатов не происходит не заметили? А отсутствие requirements.txt в глаза не бросилось?)

Ну пользуетесь LLM - да ради Бога, но зачем писать про "сам", так как будто здесь никто не видел как пишет модель и не считывает характерные паттерны?

[Telcontar]

Андрей Прохоренко, за Kilo code будете отвечать?

[Telcontar]

Алексей Уколов, вы кажись в модераторах состоите ЕМНИП? Снесите этот ответ, пожалуйста, а заодно и вопрос.

[Андрей Прохоренко]

Алексей Уколов, и это расширение vscode которое я добавил в гит хаб а не оно за меня не кодит. и у меня подписки claude code нет и платить ее не собираюсь и тем более за бесплатные ответ покупать платные подписки нет смысла. Claude code работает только на платных подписках pro и max
я отправляю коммит сам лично и расширение добавляет все на гит через это расширение в vscode.
kilo code там только бесплатные LLM для простых запросов как поиск googlу и не более.
А бесплатные LLM не ответят ничего так как это сделает claude code

[Наталия]

Писать batch в БД периодически по ходу парсинга, а не только в конце.

- вот за это спасибо, это добавила! остальное к сожалению никак не влияет по моим ощущениям, пока оставила "на подумать". Проблема не решена пока.
И замечу, что код у меня был не рабочий, я оставила там файлы типа "auth_ui.py" вместо "ui.py", потому что копирую их вручную из claude, а в claude code меня уже забанили и я понимаю, как это всё работает))

[Андрей Прохоренко]

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

[Наталия]

dim5x, хорошая проверка вышла) всегда буду подкладывать нерабочие файлы в репозиторий теперь))

[Андрей Прохоренко]

Наталия, а зачем в гит выкладывать не рабочие файлы. Лучше не доверять LLM моделям на 100% а использовать как помощника в кодинге. LLM модели никогда не сделают идеально и нужно для LLM моделей все разжевать как обычному школьнику и только тогда она тебе более качественно ответит а если так не сделать будет как у тебя и вышло