1 puntos por freedomzero 2026-03-26 | Aún no hay comentarios. | Compartir por WhatsApp

Hola, les presento LogXide para quienes sufren cuellos de botella de I/O de archivos y logging en entornos de alta carga, como aplicaciones web en Python y pipelines de datos.

1. Por qué lo hice (The Problem)

El módulo logging estándar de Python está escrito en Python puro. En entornos normales es suficiente, pero en picos de tráfico o en pipelines de logging a gran escala, ocupa el GIL (Global Interpreter Lock) durante las operaciones de I/O y termina degradando el rendimiento de toda la aplicación.

2. Cómo lo resolví (Architecture)

LogXide escribe la lógica central y los handlers en Rust y los enlaza con PyO3.

  • Python-side Level Check: se agregó FastLoggerWrapper para que, cuando un nivel de log está desactivado (por ejemplo, una llamada DEBUG con el nivel INFO configurado), se descarte de inmediato del lado de Python sin crear PyObject ni cruzar el límite de PyO3. Con esta optimización, la velocidad en llamadas vacías mejoró entre 2 y 5 veces.
  • I/O no bloqueante: StreamHandler, HTTPHandler y OTLPHandler procesan logs de forma asíncrona usando canales crossbeam y un hilo en segundo plano. No bloquean el hilo principal de la aplicación.
  • write directo síncrono: en el caso de FileHandler, realiza I/O directo al sistema operativo usando Mutex<BufWriter> y hace flush solo cuando es necesario, reduciendo al extremo el overhead de I/O.

3. Benchmarks principales (macOS ARM64, Python 3.12)

  • FileHandler: 2.09M msgs/sec (12.5 veces más rápido que stdlib con 167K)
  • StreamHandler: 2.14M msgs/sec (186 veces más rápido que stdlib con 11K)
  • En I/O real de formateo de archivos, es 25% más rápido que Picologging, escrito en C, y 2.4 veces más rápido que Structlog, escrito en Python puro.

4. Funciones integradas y uso

La estructura permite reutilizar el código existente de logging.getLogger() con solo cambiar una línea a from logxide import logging. En línea con las tendencias recientes de arquitectura backend, incorpora estos handlers a nivel nativo de Rust:

  • OTLPHandler: envío directo basado en Protobuf sin agente de OpenTelemetry
  • HTTPHandler: función de envío por lotes (Batch)
  • SentryHandler: soporte integrado para logging de errores (pip install logxide[sentry])
  • ColorFormatter: soporte para salida con color en terminal usando secuencias de control ANSI

5. Limitaciones claras (Trade-offs)

Si están evaluando adoptarlo, deben saber que no es un reemplazo drop-in al 100%:

  • No se pueden heredar ni registrar logging.Handler personalizados escritos en Python. (Para mantener el máximo rendimiento, hay que usar solo los handlers integrados implementados en Rust).
  • No se pueden subclasificar objetos Logger ni LogRecord.
  • En entornos de pytest, en lugar del caplog integrado, hay que usar el fixture caplog_logxide que ofrece LogXide.

Si estaban buscando un logger basado en C o una librería de logging estructurado por cuellos de botella de rendimiento, puede ser una excelente alternativa. La documentación oficial también incluye guías de integración listas para usar con Django, FastAPI y Flask, así que les agradecería mucho que le den un vistazo y me compartan su feedback.

Aún no hay comentarios.

Aún no hay comentarios.