WEBVTT

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

00:00:01.076 --> 00:00:03.826 align:middle
Imagine you have a performance
"problem" on production.

00:00:04.476 --> 00:00:05.026 align:middle
No worries!

00:00:05.246 --> 00:00:10.546 align:middle
Except... the issue is only caused
in some edge-case situation...

00:00:10.646 --> 00:00:14.786 align:middle
and you're having a hard time
repeating the exact condition...

00:00:15.166 --> 00:00:19.156 align:middle
which means that you can't create
a meaningful Blackfire profile

00:00:19.376 --> 00:00:21.096 align:middle
by using the browser extension.

00:00:21.096 --> 00:00:29.016 align:middle
For example, imagine we want to profile the AJAX
request that loads the GitHub repository info...

00:00:29.446 --> 00:00:34.326 align:middle
but we think that the performance problem
only happens for certain types of users -

00:00:34.766 --> 00:00:37.486 align:middle
maybe users that have many comments.

00:00:37.596 --> 00:00:38.936 align:middle
I'm just making this up.

00:00:39.776 --> 00:00:45.646 align:middle
To do that, instead of triggering a new profile
by clicking the browser extension button -

00:00:45.866 --> 00:00:50.686 align:middle
which maybe is hard because we can't
seem to replicate the correct situation -

00:00:51.076 --> 00:00:55.606 align:middle
let's trigger a new profile
automatically from inside our code.

00:00:56.506 --> 00:00:59.136 align:middle
We can do this using the PHP SDK.

00:00:59.136 --> 00:01:05.166 align:middle
Spin over, go back to MainController and
scroll down to loadSightingsPartial()...

00:01:05.786 --> 00:01:09.066 align:middle
actually to the gitHubOrganizationInfo() method.

00:01:09.066 --> 00:01:14.246 align:middle
This is the controller that returns the
content on the right side of the page.

00:01:14.406 --> 00:01:19.606 align:middle
Start by creating a fake
variable $shouldProfile = true.

00:01:21.336 --> 00:01:28.266 align:middle
In a real app, you would replace this with
logic to determine whether or not this is one

00:01:28.266 --> 00:01:34.586 align:middle
of those requests that you think might have
a performance problem: maybe you check to see

00:01:34.586 --> 00:01:37.246 align:middle
if the user has many comments or something.

00:01:38.146 --> 00:01:44.486 align:middle
Then, if $shouldProfile, it means that we
want Blackfire to profile this request.

00:01:45.526 --> 00:01:50.516 align:middle
To do that, say $blackfire = new
Client() - the one from Blackfire.

00:01:51.186 --> 00:01:55.146 align:middle
This is an object that helps
communicate with the Blackfire servers.

00:01:56.136 --> 00:02:00.376 align:middle
Next, create a probe - basically
create a new "profile" -

00:02:00.786 --> 00:02:04.196 align:middle
with $probe = $blackfire->createProbe().

00:02:05.856 --> 00:02:10.626 align:middle
Earlier, when we used
BlackfireProbe::getMainInstance(), we were,

00:02:10.916 --> 00:02:15.416 align:middle
kind of asking for a "probe" if
there was a profile happening.

00:02:15.726 --> 00:02:21.666 align:middle
But this time, we're creating a probe:
creating a new profile and telling it to start

00:02:21.836 --> 00:02:24.816 align:middle
"instrumenting" - collecting data - right now.

00:02:25.596 --> 00:02:32.056 align:middle
In fact, the second argument to createProbe() is
$enabled=true: whether or not we want the probe

00:02:32.056 --> 00:02:38.256 align:middle
to immediately start instrumentation or if we
will enable it later with $probe->enable().

00:02:39.256 --> 00:02:42.356 align:middle
Now, because this will create a new profile,

00:02:42.626 --> 00:02:46.706 align:middle
you need to make sure you do
this only rarely on production.

00:02:47.496 --> 00:02:51.196 align:middle
Why? Because creating profiles is heavy

00:02:51.316 --> 00:02:55.776 align:middle
and this slow request will be felt
by whichever user triggered it.

00:02:55.776 --> 00:02:59.436 align:middle
So, choose your logic for
$shouldProfile carefully.

00:03:00.186 --> 00:03:01.966 align:middle
Anyways, let's try it!

00:03:02.536 --> 00:03:06.066 align:middle
Move over and refresh your
list of Blackfire profiles.

00:03:08.106 --> 00:03:12.306 align:middle
The most recent one is the "Only
instrumenting some code" profile.

00:03:13.046 --> 00:03:15.546 align:middle
Now refresh the homepage.

00:03:16.586 --> 00:03:18.256 align:middle
This triggers the AJAX call...

00:03:18.626 --> 00:03:20.696 align:middle
but notice it's slower.

00:03:21.306 --> 00:03:23.156 align:middle
And when we refresh Blackfire...

00:03:24.536 --> 00:03:27.956 align:middle
boom! We have a brand new profile!

00:03:28.676 --> 00:03:30.066 align:middle
Open that up and...

00:03:30.066 --> 00:03:37.956 align:middle
let's give it a name: [Recording]
First automatic profile:

00:03:37.956 --> 00:03:41.386 align:middle
http://bit.ly/f-bf-1st-auto-profile.

00:03:41.386 --> 00:03:42.166 align:middle
I'm so proud.

00:03:42.166 --> 00:03:43.836 align:middle
You can now create new profiles
from your code...

00:03:43.836 --> 00:03:45.036 align:middle
whenever you want to.

00:03:45.576 --> 00:03:52.026 align:middle
But... there's a small problem: this
only profiled a tiny part of our code.

00:03:52.676 --> 00:03:59.606 align:middle
And, that makes sense: when our PHP code started
executing, the PHP extension didn't yet know

00:03:59.606 --> 00:04:02.446 align:middle
that we wanted to profile this request.

00:04:02.846 --> 00:04:09.156 align:middle
And so, it couldn't start collecting data until
we told it to, which happened in the controller.

00:04:10.176 --> 00:04:16.716 align:middle
To make matters worse, as soon as PHP
garbage collected the $probe variable...

00:04:17.066 --> 00:04:20.186 align:middle
which happened once the variable
isn't used anymore...

00:04:20.556 --> 00:04:26.356 align:middle
so at the end of the controller, internally,
the probe called close() on itself.

00:04:26.806 --> 00:04:32.086 align:middle
That means that we just collected data on
nothing more than the code in our controller.

00:04:32.926 --> 00:04:34.236 align:middle
How can we fix that?

00:04:34.676 --> 00:04:40.346 align:middle
By starting the probe super early and
closing it manually as late as we can.

00:04:41.046 --> 00:04:42.256 align:middle
Let's do that next.