Beyond Performance – Quality and Security Checks on Blackfire

To read more about Quality and Security Checks on Blackfire, make sure to read also More about Blackfire’s Security and Quality Recommendations

During a profiling session, Blackfire collects a lot of (non-sensitive) data. It captures metrics on function/method calls, which makes it possible to determine which frameworks and packages your code is using. Based on that information, it can offer you performance recommendations, ranging from a simple You should execute less SQL queries to more advanced, framework-specific recommendations. As of writing, we cover generic PHP, Symfony, Magento, Drupal, eZ Platform and Typo3 performance recommendations.

Beyond performance

With all the data we collect, we realized that we could actually go much further than that, beyond performance. Blackfire is all about helping you improve your code so that is consumes less resources, but as a bonus, it can also let you know if the code you’ll be pushing/you’ve pushed in production is safe and of good quality.

We added 40+ quality recommendations, and 20+ security recommendations, available as add-ons to the Profiler, Premium and Enterprise subscriptions.

Be notified every time your profile your code

From now on, anytime you profile your code, if we detect that it doesn’t comply with our best practices, you’ll be notified in the “Recommendations” tab of your profiles, or in your build results.

Of course, please note that these recommendations are not influencing the pass/fail status of your builds, as soon as you have written your own first test.

Quality recommendations

Quality recommendations aim specifically at making sure that your are pushing the right configuration in production, for instance that your php.ini file and the cache settings are optimal. Some examples below.

Checking if the APCu memory isn’t too fragmented

‘APCu memory is too fragmented, you should do less deletes or updates’:
       unless: ‘not has_apcu_sma_fragmentation_data()’
       assertions:
           - ‘runtime.apcu.sma.blocks_15th_centil_size / runtime.apcu.sma.avail_mem < 0.95’

‘APCu shared memory size should be increased to avoid using more than 85% of it’:
       unless: ‘not has_configuration(“apc_shm_size”) or not has_configuration(“apc_shm_segments”) or not runtime.apcu.cache’
       assertions:
           - ‘runtime.apcu.cache.mem_size <= runtime.configuration.apc_shm_size * runtime.configuration.apc_shm_segments * 0.85’

Checking if you’re not using PHP debug functions

PHP debug statements like var_dump(), var_export() or print_r() should not be used in production. At least, when they’re actually used for debug! Blackfire will make the difference between var_export(..., true), which is perfectly fine, and var_export(...).

Security recommendations

Having Blackfire let you know about bad practices when your code is deployed to production is very helpful. Some configuration may indeed make some sense when you’re in development, but should be updated once you move to production. But when it comes to security, the real power of Blackfire will be to prevent you from ever pushing vulnerabilities to production.

Checking dependencies for known security issues

By using our builds feature, available in Premium and Enterprise subscriptions, Blackfire is able to check your Composer dependencies even if you’re not changing your code. As soon as a new vulnerability is discovered, we’ll be able to tell you about it. Try running periodic builds on a staging server! Very complementary to your Continuous Integration workflow.

Even better, make it fully part of a continuous integration/continuous deployment process whenever you deploy your branches.

We hope you’ll enjoy those new recommendations! Did you find some that would be worthwhile adding to our list? Reach out to us!

Happy profiling,