Conversation
pana1990
changed the title
|
solve #8 |
|
|
||
| public function isBufferSizeExceeded(): bool | ||
| { | ||
| return $this->bufferSize < memory_get_usage(); |
There was a problem hiding this comment.
diría que aquí se están justando 2 conceptos. Por un lado el uso de memoria de la aplicación y por otro el uso de memoria de los traceables.
La comparación no creo que debería ser con memory_get_usage si no con el tamaño que internamente tenga guardado el traceable.
Esto último haría que cada traceable tuviera su propio buffer, que quizá individualmente no llegan al máximo pero en conjunto sí.
Por eso creo que la solución buena sería más bien una clase por encima que vaya haciendo la gestión de las trazas que se guaran en memoria. Al tener todas podría saber el tamaño real que está consumiendo todo lo relacionado con logs (y sin depender de memory_get_usage y por tanto del resto de uso que está teniendo la aplicación).
El tener una clase por encima además permitiría guardar las trazas de otra manera que no fuera en memoria o incluso cuando llegue al límite en vez de dejar de logear enviar al Storage lo que tenga actualmente.
A su vez esto podría provocar que durante la ejecución funcionara bien pero a la hora de leer el json del storage fuera mal por límite máximo de memoria. Aquí la solución sería establecer un límite máximo de logs (en vez de de buffer, porque se va a ir volcando) o directamente mejorar el parseo del json para que quepa en memoria (quizá esto tiene demasiadas implicaciones y sería para otra versión).
Esto sería un cambio más grande de infraestructura de la librería.
There was a problem hiding this comment.
2 participants
No description provided.