Extremely slow responses

[CarloCattano]

Steps to Reproduce

1. update to lastest
2. Make a request via command to the bot
3. Get response after long time , maybe even more than 1 minute

Expected behaviour

Fast as used to be

Actual behaviour

Takes a lot of time for most /commnads to return a response

Operating System

linux

Version of Python, python-telegram-bot & dependencies

python-telegram-bot 13.11
Bot API 5.7
certifi 2020.06.20
Python 3.9.2 (default, Feb 28 2021, 17:03:44)  [GCC 10.2.1 20210110]

Relevant log output

no relevant log info

Additional Context

It was extremely fast in the past , a couple of days after upgrading the slow downs started

[harshil21]

Hello,

This problem is most likely happening because of your internet connection. To test this, you can set the logger to DEBUG mode and check when the bot is receiving an update.

[Bibo-Joshi]

To elaborate harshils answer: There can be multiple reasons for updates being processed slowly. As long as the updates are in fact processed, I highly doubt that a long processing time is due to a bug in PTB. Some pointers on figuring out where the delay comes from:

• Are you using start_polling or start_webhook?
• please set the logging level to DEBUG (see the readme for more info). that way you can check how much time passes between a) you sending a message in the app and the update being fetched by the updater b) the updater fetching the update and the dispatcher processing it and c) the dispatcher starting to process the update and the bot sending a reply
• you can also measure how long bot.send_message(…)/message.reply_text(…) takes to finish
• are you using run_async?
• how many handler are registered to your dispatcher, in how many groups? Do any handlers contain CPU-intensive or otherwise blocking functionality (e.g. time.sleep?)
• how much traffic does your bot handle, e.g. as updates/second?

[CarloCattano]

Wrong label sorry . Was meant to be a question .

• Are you using start_polling or start_webhook?

start_polling

most likely happening because of your internet connection

Doubt it , I got a pretty strong a stable one

• are you using run_async?

no

• how many handler are registered to your dispatcher, in how many groups? Do any handlers contain CPU-intensive or otherwise blocking functionality (e.g. time.sleep?)

around 12 handlers and not using groups . Very simple functions with little process happening, no time.sleep

• how much traffic does your bot handle, e.g. as updates/second?

Not much , since I only gave access to it to myself and just trigger usually 1 command at the time , hence the surprise .

Thanks for the note on DEBUG , Im having a look now at the output.
Please change the tag , it was not intended as a bug report

[CarloCattano]

Its as if after a time of no activity , the bot went to a sleep state . Then the first command response comes to it , the next commands usually are faster responding .And this behavior continues every now and then

[Bibo-Joshi]

If you're hosting the bot at some provider please check with the provider. For example such behavior is well known for Heroku, IIRC.

[CarloCattano]

If you're hosting the bot at some provider please check with the provider. For example such behavior is well known for Heroku, IIRC.

Its running on a raspberry pi with a 64bit OS on the same network as the devices I use to send messages to it , thats why its weird

[CarloCattano]

Still couldn't find what the issue could be🤔

[harshil21]

what happens if you upgrade to the latest version (v20.0a0 by doing pip install python-telegram-bot --pre)? Does it still occur?

[CarloCattano]

The test examples work , but I would need to refactor all my code for the new system in 20.0

[Poolitzer]

there is a transition guide and some scripts to do the bulk of the work for you.

[CarloCattano]

Ok I switched from raspberry OS to Arch and it seems to be solved so it might have been an OS related issue.
Response times are light fast as before