Closed luca-nardelli closed 4 years ago
Actually, now that I think about it, raising the priority this much would make the listener run before the route name is event determined, giving an incomplete request object to the MetricsGenerators.
What do you think about moving the stopwatch initialization to a different, dedicated, event listener with a higher priority?
EDIT: Instead of moving only this to a higher priority listener, we could add a handler to the RequestCounter with priority 1024 and a new optional method collectStart
to the MetricsGenerator which is called at the beginning of the metrics collection (i.e. when all the other listeners have not fired yet)
I've edited the PR with the proposed collectStart
additional method and a new listener that calls it at the beginning of the kernel.request series of events
Hi again,
I've noticed that the RequestCounterListener has a default priority of 0 for the kernel.request handler. As an example, this is the number of listeners for my application that uses Api Platform.
As you can see, there is quite a lot going on even before the stopwatch is started (this now happens because the stopwatch is not started in the init method as per my previous PR). Because of this, the time measurement is not as accurate as it could be. Moreover, in my specific case I was also losing some timing of requests because one of my listeners set the response at this stage (from a cache).
Thus, I suggest raising the priority of the handler to 1024 so that it is basically fired as the first event (apart from the debug ones).