Python agent v2.32.0.28

Notes

This release of the Python agent provides a preview of a significant overhaul of our instrumentation for Tornado version 3.2 and earlier. Further improvements to our Django instrumentation are also included, allowing time spent in rendering Django sub templates to be viewed separately.

The agent can be installed using easy_install/pip/distribute via the Python Package Index or can be downloaded directly from our download site.

For a list of known issues with the Python agent see Status of the Python agent.

New Features

• Breakout of Django template rendering

  Previously when using Django templates, if the Django include tag was being used, the time spent rendering that sub template was shown under the generic Template/Render category. When the include tag is now used, a distinct metric is instead created corresponding to the rendering time for that sub template. This will appear in the transaction performance breakdown and also in sample transaction traces. In the case of sample transaction traces, as the name of the template will be included in the metric name, it now also provides additional context for understanding where any time is being spent when rendering that template.

Features Changed

• Preview of improved Tornado instrumentation

  Our instrumentation for Tornado version 3.2 and earlier has been experiencing a number of issues which could result in recording of data stopping and in some cases cause runtime exceptions which would affect the outcome of the executing web request. Upon investigation we found this has come about due to incremental changes in the internals of Tornado which were performed after we originally implemented the instrumentation for Tornado and which we didn't pick up as having being made. The Tornado developers have also recently released version 4.0 of Tornado. This version of Tornado has much more significant internal changes that result in our instrumentation failing completely.

  Before we could embark on trying to support version 4.0 of Tornado, we deemed it necessary to completely overhaul our existing instrumentation for older versions first in order to gives us good foundation on which to then implement support for version 4.0 of Tornado. This release of the agent provides a preview of the improved instrumentation for older versions of Tornado prior to version 4.0. The new instrumentation is not enabled by default and you will need to explicitly enable it. We have provided it as an opt in change at this point to allow you to properly test with the update first and provide us with any feedback on it and any remaining issues you may find.

  To enable the preview of the new Tornado instrumentation, you will need to add to the [newrelic]section of the agent configuration file the setting:

  feature_flag = tornado.instrumentation.r2

  카피

  If you are running on Heroku and are not using an agent configuration file, you can instead set the NEW_RELIC_FEATURE_FLAG environment variable. You can do this by running the Heroku command:

  heroku config:set NEW_RELIC_FEATURE_FLAG=tornado.instrumentation.r2

  카피

Bug Fixes

• When an exception was raised by a WSGI application during the yielding of response content via a generator, the recording of that web request by the agent may not be closed off properly. This would result in no further web requests handled by that thread being recorded and reported. If this occurred for all request handler threads, then no data would then be reported for the whole web process. This issue relates to behaviour of the Python garbage collector and when Python objects are destroyed. At this point in time we believe this only affects users of pypy and does not affect users of CPython as the reference counting model of CPython usually gives more deterministic behaviour around when Python objects are destroyed. We don't however rule out that it could affect CPython and may explain a situation matching this problem we have seen in a couple of cases where users were using uWSGI.

• When attempting to use Tornado as a worker for gunicorn, an exception could occur on startup which would result in gunicorn failing immediately and exiting. In order to use this combination it was previously necessary to disable the gunicorn specific instrumentation related to WSGI applications by adding to your agent configuration file:

  [import-hook:gunicorn.app.base] 
  enabled = false

  카피

  If you were using the Tornado worker with gunicorn and using this workaround, the underlying problem has now been addressed and you should be able to remove that section from your agent configuration file.

• The mechanism we used for applying function wrappers for instrumentation was not being performed in the most optimal way for methods of classes. This could result in problems, including unexpected runtime exceptions, especially when trying to apply instrumentation to class methods, or methods of an existing instance of a type.