Scroll down to the script below, click on any sentence (including terminal blocks!) to jump to that spot in the video!
Often, your production server will have different - hopefully bigger - hardware than your staging server... which means that your staging builds may run slower than production. That's going to be a problem if you have time based metrics: the wall time of a build may be less than 100ms on production... but more than that on staging. That means the staging builds will always fail. Bummer!
No worries. To help, each environment can define variables. Check it out: inside
the metric expression, I'll add a set of parentheses around the
100ms and then
say times and call a
var() function. I'll invent a new variable:
and give it a default value - via the 2nd argument - of 1.
Now, when this assertion is executed, it will assert that the wall time is less
than 100ms times whatever this
speed_coefficient variable is. What is
speed_coefficient? It's totally something I just made up and it is not set
anywhere. Where do we set it? Inside our Blackfire environment!
Copy the variable name and go into the Non-Master environment. On the right, near the bottom, click the pencil icon to edit our variables. Add the variable set to... how about 2: that will allow the staging server to be twice as slow.
Do we also need to set this inside the "Production" environment? Nope: I'll just let it use the default value of 1.
Let's try it! Spin back over to your terminal, add the change... and commit:
git add .git commit -m "adding speed_coeffient variable for wall time assert"
As a reminder, we're on the
some_feature branch. So when we run:
symfony deploy --bypass-checks
We're deploying to that environment.
When that finishes... move back over to the Blackfire environment, refresh and...
hello new build! Look inside. There are two cool things. First, under the homepage,
you can see the
speed_coefficient in action - the little "2" tells us the value
it's using. So, in reality, it's asserting that 50.8ms is less than 200
The other thing I want you to notice is that, if you go back to the builds page,
we have now built the
some_feature branch twice. When you click on the second,
newer build, it has the comparison stuff! It allows us to compare this build
to the previous commit on the same branch. This allows you to see -
commit-by-commit - when a feature started having performance problems.
And... that's it for the Blackfire tutorial! I hope you loved this nerdy trip into the depths of performance as much as I did. Blackfire can give you a lot of info immediately... or you can really dive in and make it sing. Personally, I love having the builds and this performance history for SymfonyCasts.com. Oh, and a special thanks to Jérôme Vieilledent - I almost definitely just slaughtered his name - for his endless patience answering my hundreds of Blackfire questions.
And as always, if you have any questions... or we didn't explain something you wanted to know about... or you want a cake recipe... we're here for you in the comments. If you have any serious performance wins, we would love to hear about them.
Alright friends - I wish you a speedy day! Seeya next time!