Caution: The documentation you are viewing is
for an older version of Zend Framework.
You can find the documentation of the current version at:
Zend_Db_Profiler - Zend_Db
Zend_Db_Profiler can be enabled to allow profiling of queries. Profiles include the queries processed by the adapter as well as elapsed time to run the queries, allowing inspection of the queries that have been performed without needing to add extra debugging code to classes. Advanced usage also allows the developer to filter which queries are profiled.
Enable the profiler by either passing a directive to the adapter constructor, or by asking the adapter to enable it later.
The value of the 'profiler' option is flexible. It is interpreted differently depending on its type. Most often, you should use a simple boolean value, but other types enable you to customize the profiler behavior.
A boolean argument sets the profiler to enabled if it is a TRUE value, or disabled if FALSE. The profiler class is the adapter's default profiler class, Zend_Db_Profiler.
An instance of a profiler object makes the adapter use that object. The object type must be Zend_Db_Profiler or a subclass thereof. Enabling the profiler is done separately.
The argument can be an associative array containing any or all of the keys 'enabled', 'instance', and 'class'. The 'enabled' and 'instance' keys correspond to the boolean and instance types documented above. The 'class' key is used to name a class to use for a custom profiler. The class must be Zend_Db_Profiler or a subclass. The class is instantiated with no constructor arguments. The 'class' option is ignored when the 'instance' option is supplied.
Finally, the argument can be an object of type Zend_Config containing properties, which are treated as the array keys described above. For example, a file "config.ini" might contain the following data:
This configuration can be applied by the following PHP code:
The 'instance' property may be used as in the following:
At any point, grab the profiler using the adapter's getProfiler() method:
This returns a Zend_Db_Profiler object instance. With that instance, the developer can examine your queries using a variety of methods:
getTotalNumQueries() returns the total number of queries that have been profiled.
getTotalElapsedSecs() returns the total number of seconds elapsed for all profiled queries.
getQueryProfiles() returns an array of all query profiles.
getLastQueryProfile() returns the last (most recent) query profile, regardless of whether or not the query has finished (if it hasn't, the end time will be NULL)
clear() clears any past query profiles from the stack.
The return value of getLastQueryProfile() and the individual elements of getQueryProfiles() are Zend_Db_Profiler_Query objects, which provide the ability to inspect the individual queries themselves:
getQuery() returns the SQL text of the query. The SQL text of a prepared statement with parameters is the text at the time the query was prepared, so it contains parameter placeholders, not the values used when the statement is executed.
getQueryParams() returns an array of parameter values used when executing a prepared query. This includes both bound parameters and arguments to the statement's execute() method. The keys of the array are the positional (1-based) or named (string) parameter indices.
getElapsedSecs() returns the number of seconds the query ran.
The information Zend_Db_Profiler provides is useful for profiling bottlenecks in applications, and for debugging queries that have been run. For instance, to see the exact query that was last run:
Perhaps a page is generating slowly; use the profiler to determine first the total number of seconds of all queries, and then step through the queries to find the one that ran longest:
In addition to query inspection, the profiler also allows the developer to filter which queries get profiled. The following methods operate on a Zend_Db_Profiler instance:
setFilterElapsedSecs() allows the developer to set a minimum query time before a query is profiled. To remove the filter, pass the method a NULL value.
setFilterQueryType() allows the developer to set which types of queries should be profiled; to profile multiple types, logical OR them. Query types are defined as the following Zend_Db_Profiler constants:
Zend_Db_Profiler::CONNECT: connection operations, or selecting a database.
Zend_Db_Profiler::QUERY: general database queries that do not match other types.
Zend_Db_Profiler::INSERT: any query that adds new data to the database, generally SQL INSERT.
Zend_Db_Profiler::UPDATE: any query that updates existing data, usually SQL UPDATE.
Zend_Db_Profiler::DELETE: any query that deletes existing data, usually SQL DELETE.
Zend_Db_Profiler::SELECT: any query that retrieves existing data, usually SQL SELECT.
Zend_Db_Profiler::TRANSACTION: any transactional operation, such as start transaction, commit, or rollback.
As with setFilterElapsedSecs(), you can remove any existing filters by passing NULL as the sole argument.
Using setFilterQueryType() can cut down on the profiles generated. However, sometimes it can be more useful to keep all profiles, but view only those you need at a given moment. Another feature of getQueryProfiles() is that it can do this filtering on-the-fly, by passing a query type (or logical combination of query types) as its first argument; see this section for a list of the query type constants.
A Specialized Profiler is an object that inherits from Zend_Db_Profiler. Specialized Profilers treat profiling information in specific ways.
All data is sent via the Zend_Wildfire_Channel_HttpHeaders component which uses HTTP headers to ensure the page content is not disturbed. Debugging AJAX requests that require clean JSON and XML responses is possible with this approach.
Firefox Browser ideally version 3 but version 2 is also supported.
Firebug Firefox Extension which you can download from » https://addons.mozilla.org/en-US/firefox/addon/1843.
FirePHP Firefox Extension which you can download from » https://addons.mozilla.org/en-US/firefox/addon/6149.
Example #1 DB Profiling with Zend_Controller_Front
Example #2 DB Profiling without Zend_Controller_Front