New module: dbprofiler

[stojg]

Hello everyone!

We have create a module that gives us some introspectives into how
silverstripe interacts with the database.

https://github.com/stiglindqvist/dbprofiler

This module is really only for development and profiling, and should
as is never be deployed to a production environment.

We hope that this module help developers to profile their code and
helping out the core development.

The module has only been tested in a MySQL environment, and if needing
to usage on other database types, needs to be adjusted to it.

The installation should be easy, just clone and change your database
to ProfilerMySQLDatabase. See the readme on the github and in the
source.

This is the information that the profiler supplies at the bottom of
the browser:

PHP peak memory: - the peak memory used by the page

Querysize - how big is the size of all sql queries combined that get
sent
to the database

Queries - How many queries that was sent do the database and how many
of
them that was unique.

Time in db - How long time was spent waiting for the database

Read more - a link to a detailed page with more information

Please check it out and provide feedback!

[Ingo Schommer]

Hey Stig,

Thats going to be very useful to sift through the monstrous SilverStripe-generated queries heh.

One caveat: You assume that the website uses _ss_environment.php. You can configure the DB class in mysite/_config.php as well, like this:

// after conf/ConfigureFromEnv.php inclusion

global $databaseConfig;

$databaseConfig['type'] = 'ProfilerMySQLDatabase';

Do you want to add these instructions to the README?

Extending (rather than decorating) the database class is obviously not ideal - do you have suggestions on clean and performant extension points in core around this? 

I'd like to see this built out into a developer toolbar (think Firebug for SilverStripe).

Here's a (kinda old) ticket relating to this: http://open.silverstripe.org/ticket/1972

Andreas Piening (https://github.com/smindel) has been working on a toolbar module,

although I don't know where he got to with that. I think the Symfony toolbar is a quite useful example

where I'd like to head with this: http://www.symfony-project.org/book/1_0/16-Application-Management-Tools

Stig, I know you're solving a very specific problem (debugging queries),

but perhaps you're make your module the first use case for a more general toolbar approach?

By the way, I think it'll help devs understand the feature quicker by having a screenshot, e.g. this one: https://skitch.com/chillu/ru1xi/home-your-site-name. You can add this straight to the README.md on github, and/or when you register your module on silverstripe.org/modules :)

[Daniel Lindkvist]

Hi,

 

I did the initial version of the dbprofiler. I believe I had to put that code in _ss_environment.php because when reaching _config.php the settings had already been set when running an older version of silverstripe. I think in current versions It only uses the class which is specified in the SS_DATABASE_CLASS constant. So there’s a possibility that we can ditch the _ss_environment.php requirement.

 

The reason for extending the MySQLDatabase class was to not make any hacks in core. But pretty much the same decoration hook made to the extended class can be made to the core class instead. That would also enable any other handling to be hooked in around query execution as well. Decorator in this case is not an actual  silverstripe decorator but the design pattern. However, it would require some strict permission checking since I for one wouldn’t want the SQL to be viewable on a live site, unless I’m logged in as admin or such.

 

I totally agree that a generic debug toolbar would be awesome and really useful for developers. I’d figure it could be something quite light weight which is easy to hook debug modules to. That way it’s easier to let the community provide cool functionality to it J

 

/Daniel

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To post to this group, send email to silverst...@googlegroups.com.
To unsubscribe from this group, send email to silverstripe-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.

[stojg]

Hi!

Yes, my ideas was taken from the http://code.google.com/p/zfdebug/
ZFDebug toolbar project that I'm using in other projects.

In my point of view and to kind of take ideas from the ZF these things
would to include in Core to apply this cleanly and making it more
general.

1) A way to attach a profiler cleanly
There is the Zend Framework way to add a profiler when setting up the
database params:
http://framework.zend.com/manual/en/zend.db.profiler.html

And there is the way of using a the Observer pattern on SS_Database
that would perhaps fit SS architecture better..?

Still we need to send a message to the profiler before and after we
execute queries so that it can start measurements. And as it look now
it has to be done on the database adapters level (MySQLDatabase,
SQLite3Database, etc).
Probably somewhere around where it checks for 'previewwrite' request
params.

The actually logic for notifying the profiler should probably be in
the SS_Database.
The interface for the profilers could probably be very small with
start(), stop(), getTime(), getQuery() and so on.

Any thoughts out there?!

2) To make a general toolbar

I miss the possibility to hook into a Controller shutdown loop. Right
now we crank out the toolbar below the </html> with of a
__destruct().. not super cool.

So I've got no bright idea right now how to hook into the end of the
dispatch and prepending the html with the toolbar code.

I haven't really figured out the whole Controller / SS_HTTPRequest
activity flow with multiple controller stacked and relaying to
others..

[Ingo Schommer]

On Wednesday, March 9, 2011 4:33:50 AM UTC+13, stojg wrote:

Hi!

Yes, my ideas was taken from the http://code.google.com/p/zfdebug/
ZFDebug toolbar project that I'm using in other projects.

In my point of view and to kind of take ideas from the ZF these things
would to include in Core to apply this cleanly and making it more
general.

In the past we've favoured an approach where core is modified to allow these things

to become a module, and if they prove to be stable, well used, well maintained

we can look at "graduating" into core.

And there is the way of using a the Observer pattern on SS_Database
that would perhaps fit SS architecture better..?

We effectively use Extension in this capacity (with $this->extend() calls),

but don't want to slow down the system unnecessarily. Do you perhaps want

to benchmark a bit with Object::add_extension('Database', 'MyProfiler')?

The Zend approach seems to be one profiler instance per database variation,

which is less of a performance impact. Do you see any need for attaching

multiple profilers/observers? 

Still we need to send a message to the profiler before and after we
execute queries so that it can start measurements. And as it look now
it has to be done on the database adapters level (MySQLDatabase,
SQLite3Database, etc).
Probably somewhere around where it checks for 'previewwrite' request
params.

As we control all existing database modules, we can make changes happen fairly

quickly across the different implementations. I'd prefer the Database subclasses

to be a bit less monolithic, but thats a different topic :)