Python agent v1.4.0.137

Notes:

This release of the Python agent introduces a number of new features including improvements to RUM browser traces. Performance of the agent has also been improved though reducing some of the overheads when dealing with tracking SQL database queries.

For a list of known issues with the Python agent see our online help article on the status of the Python agent.

New features:

• The agent now collects additional application tier transaction trace samples for slow transactions and will correlate them with any corresponding RUM browser trace.
• Slow transaction traces will now show a figure corresponding to the amount of CPU burn that occurred during the period the transaction was running. This can be used to get an indication of whether code being executed was CPU intensive or principally waiting on I/O.
• Slow transaction traces for web requests will now provide an indication of how many concurrent requests were executing at the same time in the process the request was being handled. This can be used to determine how busy the process was at that time, but would also be used in conjunction with the recorded CPU burn to determine whether CPU burn was all from the one transaction or could also be due to parallel executing web requests in a multithreaded application. Note that this measure is dependent on an optional C extension component of the agent being able to be installed at the time of installation of the agent.
• Slow transaction traces for web requests will now display information about the amount of request content read and the amount of response content generated. This will include details about what methods of 'wsgi.input' were used to read content and how long it in total took to read the request content. Similar details are also provided about how response content was generated and how long it took from start to finish.
• Slow transaction traces for web requests will now display the value of any frontend queueing time within the server stack which pertained to that specific request. Note that this is dependent on the server stack having being configured to introduce the required header to allow queueing time to be measured. The Python agent recognises the 'X-Queue-Start' header.
• Automatic support is now provided for tracking frontend queueing time within the server stack when an application is deployed to Heroku.
• An API call and means via the WSGI environ dictionary is now provided for indicating that a transaction should not be a candidate for slow transaction traces. This is to allow one to ignore transactions which are known to always be slow. The API call is 'newrelic.agent.suppress_transaction_trace()'.
• Calls to Django APIs for sending emails will now be tracked in the performance breakdown for transactions, as well as being displayed in slow transaction traces.
• Support for Celery 3.0.

Bug fixes/Improvements:

• Overheads within the agent which could affect performance of the application have been reduced. The improvements specifically revolve around the processing of SQL database queries. This is principally to address larger than expected overheads seen by a very small subset of users which had large or more complicated SQL queries. The changes could though still result in a small general reduction in overhead and CPU usage directly attributable to the monitoring down by the agent when SQL database queries are being tracked.
• Where it is possible to build C extension components at the time the agent is installed, optional C speedups for JSON will now be installed. This reduces the overhead of JSON encoding when data is being sent by the agent to the New Relic data collector on each one minute harvest cycle. If the C extension cannot be compiled, the agent will fall back to using pure Python code as it has done in prior versions of the agent.
• Django instrumentation has been improved and issues addressed with the way that instrumentation wrappers were applied to view handlers. For example, when a view handler is passed to a view middleware, any instrumentation wrapper is now removed. This is because the wrapper could cause issues for some code which tried to do a direct comparison between the view handler passed and an expected value. It is believed this change will fix issues when using Mezzanine.
• A sporadic issue with the data collector rejecting uploaded data due to what it believes was malformed JSON should be addressed. This was due to some metric values being aggregated as integers rather than as float values. This resulted in overflow of 64 bit values in the data collector due to Python supporting arbitrary length integers and thus being able to send values larger than 64 bits.
• The agent will now no longer fail on import when -OO option is used with the Python interpreter to enable highest level of optimisation. This was an issue as -OO strips documentation strings from code and the agent was not handling the case that the documentation string would then be a None object.