Improve quality of event performance tracking
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 35/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Bastante claro
- Estado de actividad
- Estancado
- Stack tecnológico
- php
- Área
- observability, performance
Línea de trabajo
Comienza localizando el recopilador de datos de eventos y la implementación de wildcard-listener del núcleo de October descrita en la issue. Comprueba cómo se ordenan las prioridades de los listeners y, a continuación, verifica que las mediciones abarquen la ejecución completa del evento y que los datos de tiempo recopilados se registren para cada evento.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Remake of https://github.com/rainlab/debugbar-plugin/issues/42 by @LukeTowers.
Right now performance / timing tracking on events uses the difference between when the last event was fired to when the current event was fired to say how long a given event took to process. This is obviously wildly inaccurate and unhelpful, so it would be better if we could instead implement our own event data collector that actually tracked how long a given event was taking to execute by hooking one wildcard listener as the highest priority listener (with PHP_INT_MAX) and another wildcard listener as the lowest priority listener (with PHP_INT_MIN) and then recording the timing difference between those two listeners being fired.
This would require a change being made to the October core as currently wildcard listeners don't support subscribing to events with priority, and even if they did you'd still have to ensure that they were added to the priority stream of the non-wildcard listeners correctly.
Something roughly like the following:
$events->listen('*', [$this, 'onWildcardEventStart'], PHP_INT_MAX);
$events->listen('*', [$this, 'onWildcardEventEnd'], PHP_INT_MIN);
}
protected $timings = [];
public function onWildCardEventStart($name = null, $data = [])
{
if (empty($name)) { return; }
$this->timings[$name] = microtime(true);
}
public function onWildCardEventEnd($name = null, $data = [])
{
if (empty($name)) { return; }
$this->addMeasure($name, $this->timings[$name], microtime(true), $this->prepareParams($data));
}
- Lenguaje dominante
- PHP
- Estrellas
- 11
- Forks
- 9
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de wintercms/wn-debugbar-plugin
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 58/100
wintercms/wn-debugbar-plugin#26 · 1 comentario ·
-
Dificultad 3/5 1-2 días Aptitud para principiantes 35/100
wintercms/wn-debugbar-plugin#25 · 2 comentarios ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 25/100
wintercms/wn-debugbar-plugin#15 · 4 comentarios ·
Todos los issues de wintercms/wn-debugbar-plugin
Issues similares
-
sync-en
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
Los mantenedores suelen responder en 1 día
-
bug Feature: Kiosk
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
Los mantenedores suelen responder en 1 día
-
Infrastructure: actions Module: zmscitizenapi Module: zmsentities php Type: Bug unit tests
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
it-at-m/eappointment#3480 ·
Los mantenedores suelen responder en 1 día
-
HttpClient
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Los mantenedores suelen responder en 1 día
-
CI: composer install fails — league/flysystem 1.x blocked by security advisory GHSA-cxf4-7mrp-vvprAbiertodevops type: bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
Los mantenedores suelen responder en 1 día