Profiler

[John Cox]

Just a couple of notes on the profiler I am writing, so we can
discuss:

It's use is for dev purposes only. I am going to have a config var to
turn it on and off.

What I plan to do is turn on the mysql query log, and then display
each query in div which can be activated on the page. I'm just going
to write or borrow a simple slider js. So I will have each and every
query captured. I think I am going to have to do this in the
index.php page, unless we can think of a better place to put it. At
the beginning of each and every page load I will delete the log, and
write to it again. Should I make a configuration to skip the delete
on the log?

I'll grab the log, and then allow an ajax call to EXPLAIN the query.
Should I also get the mysql profiler data as well?

For PHP, I'd like to grab the functions being called and order, but I
haven't looked to see if I can get that data.

I will get the memory used.

Should I also provide a way to filter out the core calls on all of
this? I think I can do that relatively easily.

I'll also grab the vars that are floating around out there.

Also, obvious microtime, etc.

Other ideas?

[Jo]

Thanks for the info. Probably going to add more questions rather than
useful comment at this stage. I need to sit and think about it a bit
more to be useful.

On Jun 17, 8:11 pm, John Cox <john.cox...@gmail.com> wrote:

> It's use is for dev purposes only.  I am going to have a config var to
> turn it on and off.

Sounds like the easiest. Should we have different levels of profiling/
logging and some switch for them?

> What I plan to do is turn on the mysql query log, and then display
> each query in div which can be activated on the page.  I'm just going
> to write or borrow a simple slider js.  So I will have each and every
> query captured.  I think I am going to have to do this in the
> index.php page, unless we can think of a better place to put it.  At
> the beginning of each and every page load I will delete the log, and
> write to it again.  Should I make a configuration to skip the delete
> on the log?

It could be useful to have a continuous log somewhere - perhaps a
separate one from your page loaded log? This would allow analysis over
time for example, or time period. Perhaps it's not useful for the
majority.

> I'll grab the log, and then allow an ajax call to EXPLAIN the query.
> Should I also get the mysql profiler data as well?

I think the profiler data would be very useful if you could do that.
We'd be able to capture slow queries, perhaps there might be some
options - eg to capture queries only over a certain time duration.

> For PHP, I'd like to grab the functions being called and order, but I
> haven't looked to see if I can get that data.
>
> I will get the memory used.
>
> Should I also provide a way to filter out the core calls on all of
> this?  I think I can do that relatively easily.

I guess that could be a useful option for profiling a given app
someone is developing, so I'd say yes if it's easy.

> I'll also grab the vars that are floating around out there.
>
> Also, obvious microtime, etc.
>
> Other ideas?

xdebug has some useful output for both profiling and debugging. I'm
not sure if we could take advantage of that in some way; firstly to
grab more ideas for our own use, and then perhaps to provide an option
to extend our own profiler with xdebug output in some way.

That's all for now. I'llspend some more time thinking on it. This will
be a fantastic tool to have at the ready when developing an app.

[John Cox]

On Thu, Jun 17, 2010 at 10:01 AM, Jo <joj...@gmail.com> wrote:

Thanks for the info. Probably going to add more questions rather than
useful comment at this stage. I need to sit and think about it a bit
more to be useful.

On Jun 17, 8:11 pm, John Cox <john.cox...@gmail.com> wrote:

> It's use is for dev purposes only.  I am going to have a config var to
> turn it on and off.

Sounds like the easiest. Should we have different levels of profiling/
logging and some switch for them?

I plan on a div where you can pull up the information, and there will be multiple parts.  What kind of levels are you thinking?

 

> What I plan to do is turn on the mysql query log, and then display
> each query in div which can be activated on the page.  I'm just going
> to write or borrow a simple slider js.  So I will have each and every
> query captured.  I think I am going to have to do this in the
> index.php page, unless we can think of a better place to put it.  At
> the beginning of each and every page load I will delete the log, and
> write to it again.  Should I make a configuration to skip the delete
> on the log?

It could be useful to have a continuous log somewhere - perhaps a
separate one from your page loaded log? This would allow analysis over
time for example, or time period. Perhaps it's not useful for the
majority.

Maybe another cofig var to roll the log, or end it with the page view?  This would be for SQL only though.

 

> I'll grab the log, and then allow an ajax call to EXPLAIN the query.
> Should I also get the mysql profiler data as well?

I think the profiler data would be very useful if you could do that.
We'd be able to capture slow queries, perhaps there might be some
options - eg  to capture queries only over a certain time duration.

You can do a slow_query_log in mysql, instead of all queries.  The problem is, most folks aren't working with much of a data set, and the problems won't be evident without 100k records in place in some cases.  The explain on all would at least tell the ones that are going to have problems.  Perhaps another config var for that though?

 

> For PHP, I'd like to grab the functions being called and order, but I
> haven't looked to see if I can get that data.
>
> I will get the memory used.
>
> Should I also provide a way to filter out the core calls on all of
> this?  I think I can do that relatively easily.

I guess that could be a useful option for profiling a given app
someone is developing, so I'd say yes if it's easy.

Just a config var to where you do the API call.  Just adds a line or two of code.

 

xdebug has some useful output for both profiling and debugging. I'm
not sure if we could take advantage of that in some way; firstly to
grab more ideas for our own use, and then perhaps to provide an option
to extend our own profiler with xdebug output in some way.

The problem with xdebug is the install, and then the horrible slowness when activated.  It may have changed since I last looked, but isn't it still a PECL module?