Se refactoriza toda la comunicación con la API de Telegram para solucionar un problema de latencia severa en el entorno Docker. El problema era causado por un retraso en la resolución de red. - Se mejora la función en para forzar el uso de IPv4, añadir timeouts y soportar métodos GET/POST. - Se centraliza la lógica de la API en la clase , añadiendo los métodos , y . - Se modifica para que utilice los nuevos métodos centralizados, eliminando código cURL duplicado y aplicando la solución de red. - Se mantiene la instrumentación en para futuros diagnósticos, según lo solicitado.
2.2 KiB
2.2 KiB
Plan de Diagnóstico de Rendimiento del Bot de Telegram
Este archivo rastrea los pasos para diagnosticar la latencia en las respuestas del bot cuando se ejecuta en Docker.
Análisis Final
- Diagnóstico Definitivo: El problema no era la base de datos, sino 100% la capa de red. Cada petición (
cURL) desde el contenedor Docker a la API de Telegram (api.telegram.org) sufría una demora de ~5.6 segundos. Esto se debía probablemente a un intento fallido de conexión por IPv6 antes de recurrir a IPv4. - Solución Aplicada: Se modificó la función
private function requestenbot/TelegramBot.phppara forzar el uso de IPv4 en todas las peticionescURL, además de añadir timeouts de seguridad. Se refactorizópublic/admin/webhook.phppara usar los métodos centralizados enTelegramBot.php, asegurando que la solución se aplique de manera consistente en toda la aplicación.
Pasos de Diagnóstico (Historial)
-
Paso 1: Medir Tiempos dentro del Script (Instrumentación)
- Estado: Completado.
- Análisis: Los logs revelaron que cada llamada a la API de Telegram tardaba ~5.6s, y las acciones con dos llamadas (como
ver_turnos) tardaban ~11.2s.
-
Paso 2: Diagnóstico de Red y DNS desde DENTRO del Contenedor
- Estado: Revisado.
- Análisis: La prueba inicial con
curlya apuntaba a una conexión lenta (~0.8s), lo que fue el primer indicio del problema de red.
-
Paso 3: Análisis de Recursos del Contenedor
- Estado: Cancelado.
- Análisis: Se determinó que el problema era de red, no de consumo de CPU/Memoria, por lo que este paso ya no es necesario.
-
Paso 4: Revisión y Corrección de la Capa de Red (TelegramBot.php y admin/webhook.php)
- Estado: Completado.
- Acción: Se analizó y mejoró
bot/TelegramBot.phpy se refactorizópublic/admin/webhook.phppara usar la lógica de comunicación centralizada y corregida.
-
Paso 5: Verificación de la Solución
- Estado: En progreso.
- Acción: Esperando los resultados de
logs/webhook_timing.logy la confirmación visual de la páginaadmin/webhook.phpdespués de reiniciar el contenedor y probar el bot con el parche aplicado.