3

We've just started using New Relic to monitor our D6 sites, and are also taking advantage of New Relic's ability to report on Drupal module performance.

Our sites contain several modules with configuration exports that are controlled by Features (views, content types, etc).

New Relic's module performance page shows features.module as being the slowest and as having the highest function call count.

It was my understanding that Features doesn't do too much of anything except for when you are creating/updating/reverting your features, so I'm confused as to why New Relic would report it as being such a drag in terms of site performance.

Can anyone confirm that Features does indeed significantly impact site performance? Or confirm that it doesn't (in which case this seems like a New Relic issue).

1
  • 1
    I do have seen Features doing crazy things as well. Not sure if on normal page requests but certainly on cache clears. It seems to be doing crazy things like re-saving fields and field instances. I have not found time yet to look into it, however.
    – Berdir
    Commented Apr 18, 2012 at 23:01

1 Answer 1

1

By design, Features shouldn't induce any performance hit besides what is inherent to any Drupal module. It doesn't implement hook_init() or hook_boot(), nor does it implement any hook_form_alter()s or Node API hooks, so there should literally be no Features activity on most page loads.

However, every time caches are cleared, Features does some heavy work — it interrogates all Feature modules and rebuilds Faux-Exportables.


There are two kinds of Features Components: Exportables and Faux-Exportables.

Exportables

Anything that is a CTools Exportable is also a Features Exportable, such as Views, Contexts and Panels.

On this issue thread, one of the Features maintainers says:

Generally speaking a View in the database and a View in code perform exactly the same. There are some slight differences in loading methodology (it helps to have a good PHP code cache like xcache or APC when using exportables as the data lives in code), but other than that you shouldn't see any differences.

Faux-Exportables

Faux-Exportables include content types, CCK fields, taxonomy, roles, and permissions.

Faux-Exportables are by definition stored in the database, so they do not require any intervention from Features. Features only touches Faux-Exportables when rebuilding (as mentioned above).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.