I’ve tried to add New Relic APM to my Django application using their wrapper script.
My setup has the Sentry() wrapper around the Django application WSGI handler, mainly to get the additional environment details in the requests.
I noticed however some weird numbers on New Relic, all performance numbers where basically 1000x what they should be. 2ms request came out as 2 seconds etc.
Once I removed the Sentry wrapper around my application in my Django wsgi.py file, the statistics started looking correct again.
I haven’t looked into the Raven client code yet trying to figure out how it actually works. Or done the same for the New Relic script, should the source code be available.
Any pointers, is this expected behaviour or should I raise an issue with the Raven client on GitHub?
I’m not yet decided on New Relic, any other similar products that are known to work well with Sentry?
It’s possible that it’s adding 1998ms latency, but seems unlikely. I also can’t really understand how our middleware would change that. The only thing I could think of is if our middleware executes first, and theres an error being hit, maybe it’s waiting on the errors to send and showing that as part of latency. Normally that happens in a thread though, and I’m fairly confident New Relic’s SDK isn’t smart enough to identify what any of that means.
It looked more like milliseconds where turned into seconds when the wrapper
was in place. 200ms turned into 200 seconds.
No actual latency or change in performance, just the reporting was getting
weird numbers.
I would assume Sentry middleware firing first as it’s the inner wrapper
around the Django WSGI handler class, the New Relic one is around the whole
uWSGI process.
I’ll confirm but I didn’t see having Sentry DSN configured made any
difference, so it looked more like a bug in the code somewhere rather than
a performance issue.