Python agent release notesRSS

Notes

This release of the Python agent fixes an issue when floating point values were used in headers used to calculate queueing time.

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

Bug fixes/Improvements:

• When a float value was provided in the X-Request-Start or X-Queue-Start headers as the time stamp, it was not being parsed correctly and the fractional part was being discarded. This was resulting in loss off accuracy.

Notes

This release of the Python agent contains improvements in the way that queueing time is calculated.

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

Bug fixes/Improvements:

• Resolved some issues with tracking of front-end queue time, particularly when the agent is running on an app hosted on Heroku. The agent will now more reliably parse the headers described in https://newrelic.com/docs/features/tracking-front-end-time and will automatically detect whether the times provided are in seconds, milliseconds or microseconds.

Notes

This release of the Python agent contains a fix for when reporting to multiple applications, as well as other minor bug fixes and enhancements.

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

New features:

• On the Linux platform, the agent environment now reports the total amount of system memory available.
• Added support for psycopg2cffi database module.
• Custom parameters can be associated with function trace nodes for display against transaction traces in the UI.
• The URL associated with a call to an external service will now be shown in the custom parameters section for the node in a transaction trace. Previously would have been shown as a label when hovering other the node.

Bug fixes/Improvements:

• The agent was not reporting any data where multiple applications were being listed in in the app_name configuration setting.
• Calling register_application() in the context of a module import could cause a temporary deadlock when a timeout period was specified. The potential for deadlock will now be detected and the function will return without waiting.
• When the agent was configured to capture query string parameters, a key with an empty value was being discarded and not reported.
• When using gevent mode of gunicorn, the SystemExit exception was being logged on process shutdown due to gevent sending the SystemExit exception to all greenlets and not just the main thread when sys.exit() was called.
• Instrumentation wrapping the Django reverse() function was not accepting named parameters.
• If custom parameters were used with a transaction, the HTTP response STATUS was duplicated in details related to an error raised from that transaction.
• Changes to Django instrumentation to avoid metric grouping issues resulting from raw URLs leaking through as transaction name.

Notes:

This release of the Python agent addresses an issue with under reporting of memory use on Linux, as well as other minor bug fixes and enhancements.

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

New features:

• Added support for automatically wrapping the WSGI application entry point when using the Paste HTTP server.
• Custom metrics can now be reported via the public agent API by supplying an appropriate application object as an additional argument to 'newrelic.agent.record_custom_metric()'.
• Added support for the 'psycopg2ct' database client module for PostgreSQL.
• When needing to communicate via a firewall, the proxy settings can now be set via environment variables in addition to being able to be set in the agent configuration file.
• The number of CPU cores is now being reported in the agent environment and displayed in the UI.
• A warning will now be logged in the agent log file if an older version of uWSGI is being used which has bugs with its conformance to the WSGI specification. Such older uWSGI versions would see incorrect data being reported due to the bug in uWSGI.
• A warning will now be logged in the agent log file if uWSGI is being used and the 'enable-threads' option is not being supplied to uWSGI to enable threading within the Python interpreter, a feature which is a mandatory requirement for the Python agent to be able to work.
• A range of additional logging and debugging options have been added to allow our support team to better help you when you are having issues with setting up the agent.

Bug fixes/Improvements:

• Addressed problem where memory usage was being under reported on Linux systems. The degree to which memory usage was under reported was dependent on the memory page size the system was using. If affected you can expect to see memory usage being reported jump up as it reports the correct value.
• If the local Python installation is already using a 'sitecustomize.py' file, the agent's own 'sitecustomize.py' file will ensure that the existing copy is imported and code in it executed so that existing definitions are still applied.
• Installation of the agent could fail under buildout due to a missing Python future import for the Python with statement under Python 2.5.
• Made parsing of URLs more tolerant to malformed URLs in web external calls. The agent was encountering an error when the port number of a URL was not an integer, resulting in the data for that transaction being discarded.
• Use of raw greenlets from within a transaction was failing causing an exception and the users web request to typically fail with a HTTP 500 error response.
• Configuration of the agent will no longer fail on startup if there is no 'newrelic' section in the configuration file.

Notes:

This release of the Python agent enables the ability to set apdex values and alerts for key transactions (discussed here)

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

New features:

• Added support in the agent required to enable apdex values to be specified for key transactions.
• Added support for tracking SQL database queries when using the 'oursql' database client module for MySQL.

Bug fixes/Improvements:

• The sqlite3 instrumentation was preventing the use of a sqlite3 database connection object as a context manager together with the 'with' statement.
• Suppressed the logging produced by the urllib3 module included within the bundled requests module, when making socket connections.

Notes:

This release of the Python agent focuses on providing a low-overhead thread profiler which can monitor and record executing threads for a specified time, without affecting the customer experience.

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

New features:

• Low-overhead thread profiler. A profiling session can be initiated for a period from 2 to 10 minutes. The profiler will periodically sample what all the executing threads are doing, aggregating the results together to get a statistical snapshot of where in your application most time is being spent.

Bug fixes/Improvements:

• Importing of the greenlet module was resulting in the capacity analysis report metrics being disabled, even though it was meant to only be disabled when specifically using a coroutine based WSGI server such as gevent and eventlet mode of gunicorn.
• Improvements to the instrumentation wrapper applied to the Django view handler function so that code which tries to compare the view handler to an expected value should work. Note that this is dependent upon using an equality test rather than an identity test.
• Reverted prior change which stripped the instrumentation wrapper from the Django view handler when it was passed to any Django view middleware. Improvements to the instrumentation wrapper should remove the need to do this. Having the view handler passed in with the wrapper applied is required to ensure that calls to the view handler are tracked properly where the view handler is called from within the view middleware.
• Although not strictly required due to improvements to the instrumentation wrapper applied to a Django view handler, strip the wrapper when a view handler is passed into django.core.urlresolvers.reverse() function to ensure it can correctly determine the URL mapping to the view handler.
• Disable automatic RUM header/footer insertion when using Django 1.5 and the new streaming HTTP response object is returned. This is being disabled so that the response is not buffered, thereby interfering with the streaming process. If streaming a HTML response and RUM reporting is still required, the RUM header and footer will need to be added manually.
• Instrumentation of the feedparser module was causing an exception when a file like object rather than a string was passed to the feedparser.parse() function.
• Tastypie instrumentation was failing to be applied if using Python 2.5.

Notes:

This release of the Python agent is a minor feature and bug fix release.

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

New features:

• When reporting web application performance data against multiple applications in the New Relic UI at the same time, any end user metric data will now also be reported against all applications. Previously end user metric data would only be reported against the first application.
• The environment variable 'NEW_RELIC_SSL' can now be set to enable use of a SSL connection when reporting data to our data collector. Enabling values are 'true', 'on' or '1'. This can be used on platforms such as Heroku where configuration is performed using environment variables instead of an agent configuration file.
• Added instrumentation for tracking database queries when using the 'pymysql' module for the MySQL database.

Bug fixes/Improvements:

• Fix to algorithm calculating name of function for case where function was wrapped with a decorator implemented using a class. Previously was using the name of the decorator class rather than the name of the wrapped function.
• Fix for ZeroDivision error when calculating per request CPU burn, where due to clock granularity for system the request was quick enough to effectively have zero duration.
• Fix for AttributeError when trying to process None as a slow transaction trace when in a harvest period there were browser traces but no application server traces.

Notes:

This release of the Python agent contains capacity analysis reporting, an improved sampling algorithm to ensure a wider sampling of slow transactions and added support for TastyPie, dropbox and facepy modules.

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

New features:

• Enable capacity analysis reporting where web application is single threaded or multithreaded (but not coroutine based system such as gevent and eventlet). This report helps you determine if you have enough instances deployed to keep up with request load and so tune your configuration for optimal performance.
• Criteria by which slow transaction samples are captured has been changed so as to include slow transactions for a broader range of transactions. Previously the transaction with the slowest overall response time would always be captured and reported. Whether a specific transaction will be preserved as a sample of a slow transaction will now also depend on whether a recent slow transaction had already been captured for it and give preference to recording slow transactions for a different transaction, rather than the same transaction all the time, if it is always the slowest.
• Where TastyPie is being used with Django, instead of all web transactions being handled by TastyPie being labeled against the TastyPie wrapper, the web transactions will now be aggregated against the specific methods of the resource or API object handling the request.
• Added instrumentation for the 'dropbox' Python module to track time spent calling out to the DropBox web service. A call to this web service would have been tracked previously by virtue of the 'dropbox' module internally using the 'httplib' module. This added instrumentation however makes the data collected more accurate as will properly track time spent sending the request and receiving the response. It will also attribute the call to the 'dropbox' module in transaction traces and performance breakdown data.
• Added instrumentation for the 'facepy' Python module to track time spent calling out to the Facebook web service. A call to this web service would have been tracked previously by virtue of the 'facepy' module internally using the 'requests' module. This added instrumentation however allows the call to be attributed to the 'facepy' module in transaction traces and performance breakdown data.
• Added support for gevent < 0.13.7 by way of patching an existing bug in gevent. The specific problem in gevent was patched in version 0.13.7 of that package. This change will allow older versions of gevent to also be used if there is a requirement.

Bug fixes/Improvements:

• Instrumentation for Genshi templates was failing when the OR operator was used inside of a template.
• If an exception occurred in the first call to read data from wsgi.input to get the request content, it would cause a subsequent exception when recording of response time was being finalised. This wasn't causing any impact on user requests, but would result in any metrics for that request being discarded and an error being logged in the agent log.

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.