Improve symfony response times when tracing is enabled

[rjd22]

Improve symfony response times when tracing is enabled by sending
the tracing results on kernel terminate. Kernel terminate happens
after rendering and sending the response to the client so clients
won't notice any delay.

Fixes: #464

Before change:

After change:

[Jean85]

Test are failing, but change is good! Thank you for spotting this!

[rjd22]

@Jean85 The tests are failing because of some change somewhere else sadly. I checked and have nothing to do with my change.

Most likely related to: #461

[ste93cry]

The tests are failing because of some change somewhere else sadly. I checked and have nothing to do with my change.

Yes, I'm waiting for a patch release from Symfony to update all pending PRs which are all failing to pass the CI

change is good!

This PR should include the changes discussed in the referenced issue. @rjd22 let me know if you want to work on them, being the PR's author 😉

[ste93cry]

@rjd22 can you please rebase this PR and let me know if you're willing to work on the rest of the changes 🙏?

[rjd22]

@ste93cry I will see if I can make some time later this week to revise it and add some spans.

Would kernel.request and kernel.terminate be acceptable names for the spans or do you have another suggestion?

[Jean85]

I'll mark this as a bug because I consider this a blocker for releasing the tracing instrumentation: this is not an acceptable performance degradation for the user; thanks for spotting it.

[ste93cry]

Would kernel.request and kernel.terminate be acceptable names for the spans or do you have another suggestion?

Although I don't like it because it isn't really meaningful, I would leave http.server for the first span because I think Laravel and other SDK use it already

[rjd22]

@ste93cry Then http.terminate for the second one for consistency?

[ste93cry]

Ok, I don't have any better suggestion by the way 😄

[ste93cry]

I will see if I can make some time later this week

@rjd22 Since I see no activity here and I would like to release at the beginning of the next week the new version, do you mind if I take care of finishing the work? I'm asking this to avoid both of us working on the same thing without the other knowing 😄

[rjd22]

@ste93cry I'm extremely sorry that I didn't make time to pick this up as promised. I would be really grateful if you would finish this one up.

Feel free to take it over ❤️

[ste93cry]

No problem, I don't feel good at keeping pinging people to finish the work when I'm the first one taking ages to review the PRs and I don't feel good at always taking over the work of other people, but I really wanna push the release out asap, that's all 😃 I will work on this PR in the next days, in the meanwhile thank you for the contribution so far which as always is much appreciated

[ste93cry]

After thinking again at the changes I requested, I changed my mind mainly because in the context of a traditional Symfony application the master request is the transaction and lasts for the entire application's lifecycle, so it doesn't really makes sense to represent it as a child span of the transaction. In the future though, we may want to take inspiration from the Symfony profiler to create child spans for certain pieces of the application lifecycle, e.g. the execution of the controller or the sending of the response back to the client