Configuring Environments

By Fabien Potencier, on Feb 17, 2016

As our customers are busy writing performance tests with Blackfire, we are working on the next step towards a fully automated performance testing solution.

Performance management with Blackfire is centered around the notion of environments; An environment can represent physical environments of a project: a project generally has one for development, one for staging, and one for production.

An environment is more than that; it is a collaborative workspace where developers can collaborate on profiles and builds; where they all receive notifications when something goes wrong.

And your development environment is probably different from the production one: servers, data, and traffic are not the same of course, but configuration might be different as well. You want to enable debugging on your laptop and configure aggressive caching for production. But as Blackfire tests are stored along side your code, how can you write different tests for staging and production?

The key is environments configuration. When creating a new environment, you can tell Blackfire if you want to create a development one and give the hostname for production ones:


The is_dev() function available in assertions let you write test targeted specifically at development or production environments. For instance, here is how you can express that you want no YAML parsing in production:

is_dev() or metrics.symfony.yaml.reads.count == 0

Find more useful examples in Day 12 of 24 days of Blackfire.

Besides the is_dev() development test function, you can also use variables in assertions and define different values depending on the environment. You probably want to assert that the number of SQL queries for any HTTP request is limited, but what if your development environment makes several of them to store debugging information?

You can reuse the is_dev() function:

metrics.sql.queries.count < is_dev() ? 15 : 10

But there is a better way with environment variables. Create a max_sql_queries variable in each environment with different values (10 for production and 15 for development):


Then, use the variable in your assertions:

metrics.sql.queries.count < vars.max_sql_queries

This is a much cleaner solution that scales better when you add more environments.

Happy performance testing!

Fabien Potencier

Fabien Potencier is the CEO and founder of He founded the Symfony project in 2004 as he constantly looked for better ways to build websites. Fabien is also the creator of several other Open-Source projects, a writer, a blogger, a speaker at international conferences, and the happy father of two wonderful kids.