Status of Python agent

This is a summary of limitations and known issues for New Relic's Python agent. For changes that have been made between different versions of the Python agent, see the Python agent release notes.

Agent limitations


New Relic offers introductory Tornado 4 support on the following Tornado and Python versions:

  • Tornado: 4.1, 4.2, and 4.3
  • Python: 2.6, 2.7, 3.3, 3.4, 3.5 and PyPy

The agent also supports Tornado 3.

Capacity analysis

The capacity analysis reporting (Python agent v. or higher) only works for traditional single threaded or multithreaded applications. When coroutine based systems such as gevent or eventlet are being used in conjunction with a WSGI server, the capacity analysis report will not show any data except for agent restarts.

This limitation exists because the current model by which the load of a system is calculated doesn't translate to coroutine based systems.

When using a traditional single or multithreaded application, the metric information generated by the agent to support the capacity analysis page is only captured and reported if the optional C extension component of the Python agent can be compiled and installed. Otherwise, the required metrics will not be recorded or reported and the capacity analysis report will not show any data except for agent restarts.

This limitation exists because a pure Python version of the code used to track the thread utilization metric that is used as a basis for the capacity analysis metrics would require heavy use of thread locking. We are not satisfied at this point that it would not cause a performance impact on the process. New Relic is investigating other methods that have an acceptable level of overhead when using a pure Python implementation.

The capacity analysis report will also only be available once all application instances reporting have been upgraded to version or higher of the agent. If you have a mix of old and new agent versions, the capacity analysis page will not be available.

Thread profiling

The thread profiling mechanism was introduced with version

There are limits to capturing details for greenlets when a coroutine based system is being used, such as gevent or eventlet modes of gunicorn.

With coroutine based systems, the existing threading module is monkey patched. If creating a new thread, it will actually create a greenlet instead. For the thread profiler, this means the thread profiler background thread is actually a greenlet.

A greenlet will only get a chance to run when other greenlets explicitly yield control, such as when they block. This means that when the thread sampler does get to run, it will only sample the stack for other greenlets at a point where they are blocked. It will not sample them when they are executing arbitrary code. It can completely miss execution within a greenlet if it never blocked or otherwise yielded to another greenlet.

Time being spent in pure Python code that isn't blocking will not be picked up.

Because current results are misleading when coroutines are being used, from version 1.11.0.X of the agent, the thread profiler no longer shows any information for requests when coroutines are being used.


The Python 2 httplib was renamed to http.client in Python 3. New Relic has different instrumentation for each due to the change.

Some packages, such as pies2overrides and frosted, which uses pies2overrides, now introduce a new top-level module in Python 2 that uses the Python 3 name and maps that to httplib. Our instrumentation will try to instrument the Python 3 module when it isn't using the Python 3 module.

As a workaround, disable the python 3 instrumentation but not instrumentation for httplib (python 2 instrumentation).

Add this to the newrelic.ini:

enabled = false

Third party bugs

uWSGI compliance

There is an issue when using the Python agent and uWSGI. New Relic recommends upgrading to uWSGI version 1.2.6 or higher.

There is a bug in uWSGI and the way it implements the WSGI specification. uWSGI is not calling close() on the iterable returned from a WSGI application.

The problem is fixed as of uWSGI version 1.2.6.

This bug in uWSGI doesn't affect all WSGI applications and their handling of requests, but it is affecting the data reported into New Relic.

Python wsgiref module

The wsgiref module in the Python standard library, which provides a reference implementation of a WSGI server, has a WSGI compliance bug. It does not call close() on the iterable returned from the WSGI application when the client connection is lost when streaming response content.

This means the web transaction record is not closed off properly and is reused on the subsequent request for that thread. This can result in data for multiple requests being merged together and the overall web transaction having an excessively large response time.

This issue is believed to be fixed in Python 2.7.4.

Django development server

The Django development server has a WSGI compliance bug. It does not call close() on the iterable returned from the WSGI application when the client connection is lost when streaming response content.

If using Django 1.4 onward with Python 2.7.4 or newer, you will benefit from the fix in that version of Python. For older versions of Python, a change is included in Django 1.5.1 to workaround the bug.

Gunicorn daemon mode

When using daemon mode of gunicorn, the agent can fail to start up and report data. This is due to bugs in gunicorn related to how it closes out file descriptors when daemonizing.

This issue is fixed as of gunicorn version 0.17.3.

Gunicorn gevent mode

This issue with gevent has now been fixed in gevent 0.13.7 and the Python agent works properly. Version of the Python agent also includes a workaround to allow older versions of gevent to be used.

In previous versions, when using gevent mode of gunicorn and wrapping its invocation with the newrelic-admin run-program command, the hosted web application could fail in strange ways, such as requests blocking for 1 minute periods.

The cause of this problem was related to the order in which modules were imported. The monkey patching performed by gevent did not work properly, because the Python threading module was imported before the gevent monkey patching routine was run.

Hosting mechanisms

Meinheld WSGI server

The Meinheld WSGI server is not supported. It doesn't provide monkey patching for the Python standard library, so as to allow a coroutine based application to work together with code using existing threading modules from Python standard library. This prevents the agent from working correctly.

Google App Engine

The restrictions that exist under Google App Engine, such as those on background threads, as well as how processes are managed, mean that the Python agent as it is implemented at present will not work as is.

There are no plans at this point to support Google App Engine.

Python implementations


The agent test performed by newrelic-admin validate-config does work under Jython. CPU and memory metrics is disabled and will not produce any metrics. No other testing has been done.


No testing has been performed under IronPython. We suspect that the agent will not work.

Operating systems


No testing has been performed on Windows with the Python agent. It is possible that it will run, but it is suspected it may give wrong results as certain parts of the code still need to be customised for the Windows platform.

For more help

Join the discussion about Python in the New Relic Community Forum! The Community Forum is a public platform to discuss and troubleshoot your New Relic toolset.

If you need additional help, get support at