dbi::profile.3

视频监控网络部分的协议ddns,的模块的实现代码,请大家大胆指正.

.Vb 5
\&  $h\->{Profile} = 0;
\&  $h\->{Profile} = "/DBI::Profile";
\&  $h\->{Profile} = DBI::Profile\->new();
\&  $h\->{Profile} = {};
\&  $h\->{Profile} = { Path => [] };
.Ve
.PP
Similarly, these examples have the same effect as each other:
.PP
.Vb 4
\&  $h\->{Profile} = 6;
\&  $h\->{Profile} = "6/DBI::Profile";
\&  $h\->{Profile} = "!Statement:!MethodName/DBI::Profile";
\&  $h\->{Profile} = { Path => [ \*(Aq!Statement\*(Aq, \*(Aq!MethodName\*(Aq ] };
.Ve
.PP
If a non-blessed hash reference is given then the DBI::Profile
module is automatically \f(CW\*(C`require\*(C'\fR'd and the reference is blessed
into that class.
.PP
If a string is given then it is processed like this:
.PP
.Vb 1
\&    ($path, $module, $args) = split /\e//, $string, 3
\&
\&    @path = split /:/, $path
\&    @args = split /:/, $args
\&
\&    eval "require $module" if $module
\&    $module ||= "DBI::Profile"
\&
\&    $module\->new( Path => \e@Path, @args )
.Ve
.PP
So the first value is used to select the Path to be used (see below).
The second value, if present, is used as the name of a module which
will be loaded and it's \f(CW\*(C`new\*(C'\fR method called. If not present it
defaults to DBI::Profile. Any other values are passed as arguments
to the \f(CW\*(C`new\*(C'\fR method. For example: "\f(CW\*(C`2/DBIx::OtherProfile/Foo:42\*(C'\fR".
.PP
Numbers can be used as a shorthand way to enable common Path values.
The simplest way to explain how the values are interpreted is to show the code:
.PP
.Vb 5
\&    push @Path, "DBI"           if $path_elem & 0x01;
\&    push @Path, "!Statement"    if $path_elem & 0x02;
\&    push @Path, "!MethodName"   if $path_elem & 0x04;
\&    push @Path, "!MethodClass"  if $path_elem & 0x08;
\&    push @Path, "!Caller2"      if $path_elem & 0x10;
.Ve
.PP
So \*(L"2\*(R" is the same as \*(L"!Statement\*(R" and \*(L"6\*(R" (2+4) is the same as
\&\*(L"!Statement:!Method\*(R".  Those are the two most commonly used values.  Using a
negative number will reverse the path. Thus \*(L"\-6\*(R" will group by method name then
statement.
.PP
The spliting and parsing of string values assigned to the Profile
attribute may seem a little odd, but there's a good reason for it.
Remember that attributes can be embedded in the Data Source Name
string which can be passed in to a script as a parameter. For
example:
.PP
.Vb 2
\&    dbi:DriverName(Profile=>2):dbname
\&    dbi:DriverName(Profile=>{Username}:!Statement/MyProfiler/Foo:42):dbname
.Ve
.PP
And also, if the \f(CW\*(C`DBI_PROFILE\*(C'\fR environment variable is set then
The \s-1DBI\s0 arranges for every driver handle to share the same profile
object. When perl exits a single profile summary will be generated
that reflects (as nearly as practical) the total use of the \s-1DBI\s0 by
the application.
.SH "THE PROFILE OBJECT"
.IX Header "THE PROFILE OBJECT"
The \s-1DBI\s0 core expects the Profile attribute value to be a hash
reference and if the following values don't exist it will create
them as needed:
.Sh "Data"
.IX Subsection "Data"
A reference to a hash containing the collected profile data.
.Sh "Path"
.IX Subsection "Path"
The Path value is a reference to an array. Each element controls the
value to use at the corresponding level of the profile Data tree.
.PP
If the value of Path is anything other than an array reference,
it is treated as if it was:
.PP
.Vb 1
\&        [ \*(Aq!Statement\*(Aq ]
.Ve
.PP
The elements of Path array can be one of the following types:
.PP
\fISpecial Constant\fR
.IX Subsection "Special Constant"
.PP
\&\fB!Statement\fR
.PP
Use the current Statement text. Typically that's the value of the Statement
attribute for the handle the method was called with. Some methods, like
\&\fIcommit()\fR and \fIrollback()\fR, are unrelated to a particular statement. For those
methods !Statement records an empty string.
.PP
For statement handles this is always simply the string that was
given to \fIprepare()\fR when the handle was created.  For database handles
this is the statement that was last prepared or executed on that
database handle. That can lead to a little 'fuzzyness' because, for
example, calls to the \fIquote()\fR method to build a new statement will
typically be associated with the previous statement. In practice
this isn't a significant issue and the dynamic Path mechanism can
be used to setup your own rules.
.PP
\&\fB!MethodName\fR
.PP
Use the name of the \s-1DBI\s0 method that the profile sample relates to.
.PP
\&\fB!MethodClass\fR
.PP
Use the fully qualified name of the \s-1DBI\s0 method, including
the package, that the profile sample relates to. This shows you
where the method was implemented. For example:
.PP
.Vb 4
\&  \*(AqDBD::_::db::selectrow_arrayref\*(Aq =>
\&      0.022902s
\&  \*(AqDBD::mysql::db::selectrow_arrayref\*(Aq =>
\&      2.244521s / 99 = 0.022445s avg (first 0.022813s, min 0.022051s, max 0.028932s)
.Ve
.PP
The \*(L"DBD::_::db::selectrow_arrayref\*(R" shows that the driver has
inherited the selectrow_arrayref method provided by the \s-1DBI\s0.
.PP
But you'll note that there is only one call to
DBD::_::db::selectrow_arrayref but another 99 to
DBD::mysql::db::selectrow_arrayref. Currently the first
call Pern't record the true location. That may change.
.PP
\&\fB!Caller\fR
.PP
Use a string showing the filename and line number of the code calling the method.
.PP
\&\fB!Caller2\fR
.PP
Use a string showing the filename and line number of the code calling the
method, as for !Caller, but also include filename and line number of the code
that called that. Calls from \s-1DBI::\s0 and \s-1DBD::\s0 packages are skipped.
.PP
\&\fB!File\fR
.PP
Same as !Caller above except that only the filename is included, not the line number.
.PP
\&\fB!File2\fR
.PP
Same as !Caller2 above except that only the filenames are included, not the line number.
.PP
\&\fB!Time\fR
.PP
Use the current value of \fItime()\fR. Rarely used. See the more useful \f(CW\*(C`!Time~N\*(C'\fR below.
.PP
\&\fB!Time~N\fR
.PP
Where \f(CW\*(C`N\*(C'\fR is an integer. Use the current value of \fItime()\fR but with reduced precision.
The value used is determined in this way:
.PP
.Vb 1
\&    int( time() / N ) * N
.Ve
.PP
This is a useful way to segregate a profile into time slots. For example:
.PP
.Vb 1
\&    [ \*(Aq!Time~60\*(Aq, \*(Aq!Statement\*(Aq ]
.Ve
.PP
\fICode Reference\fR
.IX Subsection "Code Reference"
.PP
The subroutine is passed the handle it was called on and the \s-1DBI\s0 method name.
The current Statement is in \f(CW$_\fR. The statement string should not be modified,
so most subs start with \f(CW\*(C`local $_ = $_;\*(C'\fR.
.PP
The list of values it returns is used at that point in the Profile Path.
.PP
The sub can 'veto' (reject) a profile sample by including a reference to undef
in the returned list. That can be useful when you want to only profile
statements that match a certain pattern, or only profile certain methods.
.PP
\fISubroutine Specifier\fR
.IX Subsection "Subroutine Specifier"
.PP
A Path element that begins with '\f(CW\*(C`&\*(C'\fR' is treated as the name of a subroutine
in the DBI::ProfileSubs namespace and replaced with the corresponding code reference.
.PP
Currently this only works when the Path is specified by the \f(CW\*(C`DBI_PROFILE\*(C'\fR
environment variable.
.PP
Also, currently, the only subroutine in the DBI::ProfileSubs namespace is
\&\f(CW\*(Aq&norm_std_n3\*(Aq\fR. That's a very handy subroutine when profiling code that
doesn't use placeholders. See DBI::ProfileSubs for more information.
.PP
\fIAttribute Specifier\fR
.IX Subsection "Attribute Specifier"
.PP
A string enclosed in braces, such as '\f(CW\*(C`{Username}\*(C'\fR', specifies that the current
value of the corresponding database handle attribute should be used at that
point in the Path.
.PP
\fIReference to a Scalar\fR
.IX Subsection "Reference to a Scalar"
.PP
Specifies that the current value of the referenced scalar be used at that point
in the Path.  This provides an efficient way to get 'contextual' values into
your profile.
.PP
\fIOther Values\fR
.IX Subsection "Other Values"
.PP
Any other values are stringified and used literally.
.PP
(References, and values that begin with punctuation characters are reserved.)
.SH "REPORTING"
.IX Header "REPORTING"
.Sh "Report Format"
.IX Subsection "Report Format"
The current accumulated profile data can be formatted and output using
.PP
.Vb 1
\&    print $h\->{Profile}\->format;
.Ve
.PP
To discard the profile data and start collecting fresh data
you can do:
.PP
.Vb 1
\&    $h\->{Profile}\->{Data} = undef;
.Ve
.PP
The default results format looks like this:
.PP
.Vb 5
\&  DBI::Profile: 0.001015s 42.7% (5 calls) programname @ YYYY\-MM\-DD HH:MM:SS
\&  \*(Aq\*(Aq =>
\&      0.000024s / 2 = 0.000012s avg (first 0.000015s, min 0.000009s, max 0.000015s)
\&  \*(AqSELECT mode,size,name FROM table\*(Aq =>
\&      0.000991s / 3 = 0.000330s avg (first 0.000678s, min 0.000009s, max 0.000678s)
.Ve
.PP
Which shows the total time spent inside the \s-1DBI\s0, with a count of
the total number of method calls and the name of the script being
run, then a formated version of the profile data tree.
.PP
If the results are being formated when the perl process is exiting
(which is usually the case when the \s-1DBI_PROFILE\s0 environment variable
is used) then the percentage of time the process spent inside the
\&\s-1DBI\s0 is also shown. If the process is not exiting then the percentage is
calculated using the time between the first and last call to the \s-1DBI\s0.
.PP
In the example above the paths in the tree are only one level deep and
use the Statement text as the value (that's the default behaviour).
.PP
The merged profile data at the 'leaves' of the tree are presented
as total time spent, count, average time spent (which is simply total
time divided by the count), then the time spent on the first call,
the time spent on the fastest call, and finally the time spent on
the slowest call.
.PP
The 'avg', 'first', 'min' and 'max' times are not particularly
useful when the profile data path only contains the statement text.
Here's an extract of a more detailed example using both statement
text and method name in the path:
.PP
.Vb 5
\&  \*(AqSELECT mode,size,name FROM table\*(Aq =>
\&      \*(AqFETCH\*(Aq =>
\&          0.000076s
\&      \*(Aqfetchrow_hashref\*(Aq =>
\&          0.036203s / 108 = 0.000335s avg (first 0.000490s, min 0.000152s, max 0.002786s)
.Ve
.PP