WEBVTT

NOTE Created by CaptionSync from Automatic Sync Technologies www.automaticsync.com

00:00:01.086 --> 00:00:06.516 align:middle
We know that the scenario will be executed
against our production server only.

00:00:07.246 --> 00:00:11.296 align:middle
If we profiled a local page,
this stuff has no effect.

00:00:11.846 --> 00:00:17.486 align:middle
That means that the results of these
profiles should have less variability.

00:00:17.736 --> 00:00:22.586 align:middle
Not no variability: if your production
server is under heavy traffic,

00:00:22.916 --> 00:00:25.236 align:middle
the profiles might be slower than normal.

00:00:25.656 --> 00:00:30.946 align:middle
But, it will have less variability than
trying to compare a profile that you created

00:00:30.946 --> 00:00:35.046 align:middle
on your local machine with a
profile created on production:

00:00:35.686 --> 00:00:38.636 align:middle
those are totally different machines and setups.

00:00:39.306 --> 00:00:40.746 align:middle
This means that you can...

00:00:40.936 --> 00:00:44.406 align:middle
maybe add some time-based assertions...

00:00:44.686 --> 00:00:46.636 align:middle
as long as you're conservative.

00:00:46.706 --> 00:00:56.186 align:middle
For example, on the homepage, let's
assert that main.wall_time < 100ms.

00:00:56.246 --> 00:00:59.176 align:middle
By the way, most metrics start with metrics.

00:00:59.176 --> 00:01:02.946 align:middle
and you can look on the timeline
to see what's available.

00:01:02.946 --> 00:01:08.346 align:middle
A few metrics - like wall time and
peak memory - start with main..

00:01:09.846 --> 00:01:12.426 align:middle
Anyways, as you can see inside Blackfire,

00:01:12.696 --> 00:01:17.826 align:middle
our homepage on production normally
has a wall time of about 50ms...

00:01:18.026 --> 00:01:21.906 align:middle
so 100ms is fairly conservative.

00:01:22.306 --> 00:01:25.166 align:middle
But time-based metrics are still fragile.

00:01:25.546 --> 00:01:30.016 align:middle
Doing this will likely result in some
random failures from time-to-time.

00:01:30.966 --> 00:01:44.456 align:middle
Let's commit this: And deploy:
While that's deploying,

00:01:44.456 --> 00:01:48.556 align:middle
I want to show you a super powerful
feature that we won't have time

00:01:48.556 --> 00:01:52.606 align:middle
to experiment with: custom metrics.

00:01:52.606 --> 00:01:54.806 align:middle
Google for "Blackfire metrics".

00:01:56.376 --> 00:02:02.116 align:middle
In addition to the timeline, this page also
lists all of the metrics that are available.

00:02:02.786 --> 00:02:08.066 align:middle
But you can also create your own
metrics inside .blackfire.yaml.

00:02:09.576 --> 00:02:14.456 align:middle
In addition to tests and scenarios,
we can have a metrics key.

00:02:14.496 --> 00:02:19.786 align:middle
For example, this creates a custom
metric called "Markdown to HTML".

00:02:20.406 --> 00:02:27.356 align:middle
The real magic is the matching_calls
config: any time the toHtml method

00:02:27.356 --> 00:02:32.036 align:middle
of this made-up Markdown class is
called, its data will be grouped

00:02:32.036 --> 00:02:34.826 align:middle
into the markdown_to_html metric.

00:02:35.806 --> 00:02:40.736 align:middle
That's powerful because you can
immediately use that metric in your tests.

00:02:40.826 --> 00:02:47.506 align:middle
For example, you could assert that this
metric is called exactly zero times -

00:02:47.776 --> 00:02:52.716 align:middle
as a way to make sure that some
caching system is avoiding the need

00:02:52.716 --> 00:02:54.816 align:middle
for this to ever happen on production.

00:02:55.656 --> 00:02:57.776 align:middle
Or, you could check the memory usage...

00:02:58.016 --> 00:02:59.146 align:middle
or other dimension.

00:03:00.236 --> 00:03:03.576 align:middle
You can use some pretty serious
logic to create these metrics:

00:03:03.876 --> 00:03:10.256 align:middle
making it match only a specific caller for a
function, OR logic, regex matching and ways

00:03:10.256 --> 00:03:15.036 align:middle
to match methods, calls from classes that
implement an interface and many other things.

00:03:16.086 --> 00:03:20.316 align:middle
You can even create separate
metrics for the same method based

00:03:20.316 --> 00:03:22.466 align:middle
on which arguments are passed to them.

00:03:22.876 --> 00:03:24.576 align:middle
They went a little nuts.

00:03:25.426 --> 00:03:27.496 align:middle
Anyways, let's check on the deploy.

00:03:28.746 --> 00:03:34.566 align:middle
Done! Go back - I'll close this
tab - and let's create a new build.

00:03:38.676 --> 00:03:41.266 align:middle
Call it "With homepage wall time assert".

00:03:42.656 --> 00:03:43.786 align:middle
Start build!

00:03:45.046 --> 00:03:47.426 align:middle
And... it passes!

00:03:48.546 --> 00:03:55.716 align:middle
This time we can see an extra constraint on the
homepage: wall time needs to be less than 100ms.

00:03:55.716 --> 00:04:01.216 align:middle
If it's greater than 100ms and
you have notifications configured,

00:04:01.416 --> 00:04:03.196 align:middle
you'll know immediately.

00:04:04.526 --> 00:04:09.756 align:middle
Next: now that we have this idea of
builds being created every 6 hours,

00:04:10.126 --> 00:04:16.406 align:middle
we can do some cool stuff, like comparing a
build to the build that happened before it.

00:04:17.096 --> 00:04:20.226 align:middle
Heck we can even write assertions about this!

00:04:20.906 --> 00:04:26.596 align:middle
Want a build to fail if a page is
30% slower than the build before it?

00:04:27.156 --> 00:04:27.836 align:middle
We can do that.