mirror of
https://github.com/sigmasternchen/php-doc-en
synced 2025-03-15 16:38:54 +00:00
1206 lines
48 KiB
XML
1206 lines
48 KiB
XML
<?xml version="1.0" encoding="utf-8"?>
|
||
<!-- $Revision$ -->
|
||
<chapter xml:id="mysqlnd.stats" xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink">
|
||
<title>Statistics</title>
|
||
<para>
|
||
<emphasis role="bold">Using Statistical Data</emphasis>
|
||
</para>
|
||
<para>
|
||
MySQL Native Driver contains support for gathering statistics on the
|
||
communication between the client and the server. The statistics
|
||
gathered are of two main types:
|
||
</para>
|
||
<itemizedlist>
|
||
<listitem>
|
||
<para>
|
||
Client statistics
|
||
</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>
|
||
Connection statistics
|
||
</para>
|
||
</listitem>
|
||
</itemizedlist>
|
||
<para>
|
||
If you are using the <literal>mysqli</literal> extension, these
|
||
statistics can be obtained through two API calls:
|
||
</para>
|
||
<itemizedlist>
|
||
<listitem>
|
||
<para>
|
||
<function>mysqli_get_client_stats</function>
|
||
</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>
|
||
<function>mysqli_get_connection_stats</function>
|
||
</para>
|
||
</listitem>
|
||
</itemizedlist>
|
||
<note>
|
||
<para>
|
||
Statistics are aggregated among all extensions that use MySQL Native
|
||
Driver. For example, when compiling both <literal>ext/mysql</literal>
|
||
and <literal>ext/mysqli</literal> against MySQL Native Driver, both
|
||
function calls of <literal>ext/mysql</literal> and
|
||
<literal>ext/mysqli</literal> will change the statistics. There is no
|
||
way to find out how much a certain API call of any extension that has
|
||
been compiled against MySQL Native Driver has impacted a certain
|
||
statistic. You can configure the PDO MySQL Driver,
|
||
<literal>ext/mysql</literal> and <literal>ext/mysqli</literal> to
|
||
optionally use the MySQL Native Driver. When doing so, all three
|
||
extensions will change the statistics.
|
||
</para>
|
||
</note>
|
||
<para>
|
||
<emphasis role="bold">Accessing Client Statistics</emphasis>
|
||
</para>
|
||
<para>
|
||
To access client statistics, you need to call
|
||
<function>mysqli_get_client_stats</function>. The function call does
|
||
not require any parameters.
|
||
</para>
|
||
<para>
|
||
The function returns an associative array that contains the name of
|
||
the statistic as the key and the statistical data as the value.
|
||
</para>
|
||
<para>
|
||
Client statistics can also be accessed by calling the
|
||
<function>phpinfo</function> function.
|
||
</para>
|
||
<para>
|
||
<emphasis role="bold">Accessing Connection Statistics</emphasis>
|
||
</para>
|
||
<para>
|
||
To access connection statistics call
|
||
<function>mysqli_get_connection_stats</function>. This takes the
|
||
database connection handle as the parameter.
|
||
</para>
|
||
<para>
|
||
The function returns an associative array that contains the name of
|
||
the statistic as the key and the statistical data as the value.
|
||
</para>
|
||
<para>
|
||
<emphasis role="bold">Buffered and Unbuffered Result Sets</emphasis>
|
||
</para>
|
||
<para>
|
||
Result sets can be buffered or unbuffered. Using default settings,
|
||
<literal>ext/mysql</literal> and <literal>ext/mysqli</literal> work
|
||
with buffered result sets for normal (non prepared statement) queries.
|
||
Buffered result sets are cached on the client. After the query
|
||
execution all results are fetched from the MySQL Server and stored in
|
||
a cache on the client. The big advantage of buffered result sets is
|
||
that they allow the server to free all resources allocated to a result
|
||
set, once the results have been fetched by the client.
|
||
</para>
|
||
<para>
|
||
Unbuffered result sets on the other hand are kept much longer on the
|
||
server. If you want to reduce memory consumption on the client, but
|
||
increase load on the server, use unbuffered results. If you experience
|
||
a high server load and the figures for unbuffered result sets are
|
||
high, you should consider moving the load to the clients. Clients
|
||
typically scale better than servers. <quote>Load</quote> does not only
|
||
refer to memory buffers - the server also needs to keep other
|
||
resources open, for example file handles and threads, before a result
|
||
set can be freed.
|
||
</para>
|
||
<para>
|
||
Prepared Statements use unbuffered result sets by default. However,
|
||
you can use <function>mysqli_stmt_store_result</function> to enable
|
||
buffered result sets.
|
||
</para>
|
||
<para>
|
||
<emphasis role="bold">Statistics returned by MySQL Native
|
||
Driver</emphasis>
|
||
</para>
|
||
<para>
|
||
The following tables show a list of statistics returned by the
|
||
<function>mysqli_get_client_stats</function> and
|
||
<function>mysqli_get_connection_stats</function> functions.
|
||
</para>
|
||
<table xml:id="mysqlnd.stats.returns">
|
||
<title>Returned mysqlnd statistics: Network</title>
|
||
<tgroup cols="4">
|
||
<colspec colwidth="10*"/>
|
||
<colspec colwidth="10*"/>
|
||
<colspec colwidth="40*"/>
|
||
<colspec colwidth="40*"/>
|
||
<thead>
|
||
<row>
|
||
<entry>Statistic</entry>
|
||
<entry>Scope</entry>
|
||
<entry>Description</entry>
|
||
<entry>Notes</entry>
|
||
</row>
|
||
</thead>
|
||
<tbody>
|
||
<row>
|
||
<entry><literal>bytes_sent</literal></entry>
|
||
<entry>Connection</entry>
|
||
<entry>Number of bytes sent from PHP to the MySQL server</entry>
|
||
<entry>Can be used to check the efficiency of the compression protocol</entry>
|
||
</row>
|
||
<row>
|
||
<entry><literal>bytes_received</literal></entry>
|
||
<entry>Connection</entry>
|
||
<entry>Number of bytes received from MySQL server</entry>
|
||
<entry>Can be used to check the efficiency of the compression protocol</entry>
|
||
</row>
|
||
<row>
|
||
<entry><literal>packets_sent</literal></entry>
|
||
<entry>Connection</entry>
|
||
<entry>Number of MySQL Client Server protocol packets sent</entry>
|
||
<entry>Used for debugging Client Server protocol implementation</entry>
|
||
</row>
|
||
<row>
|
||
<entry><literal>packets_received</literal></entry>
|
||
<entry>Connection</entry>
|
||
<entry>Number of MySQL Client Server protocol packets received</entry>
|
||
<entry>Used for debugging Client Server protocol implementation</entry>
|
||
</row>
|
||
<row>
|
||
<entry><literal>protocol_overhead_in</literal></entry>
|
||
<entry>Connection</entry>
|
||
<entry>MySQL Client Server protocol overhead in bytes for incoming traffic.
|
||
Currently only the Packet Header (4 bytes) is considered as
|
||
overhead. protocol_overhead_in = packets_received * 4</entry>
|
||
<entry>Used for debugging Client Server protocol implementation</entry>
|
||
</row>
|
||
<row>
|
||
<entry><literal>protocol_overhead_out</literal></entry>
|
||
<entry>Connection</entry>
|
||
<entry>MySQL Client Server protocol overhead in bytes for outgoing traffic.
|
||
Currently only the Packet Header (4 bytes) is considered as
|
||
overhead. protocol_overhead_out = packets_sent * 4</entry>
|
||
<entry>Used for debugging Client Server protocol implementation</entry>
|
||
</row>
|
||
<row>
|
||
<entry><literal>bytes_received_ok_packet</literal></entry>
|
||
<entry>Connection</entry>
|
||
<entry>Total size of bytes of MySQL Client Server protocol OK packets received.
|
||
OK packets can contain a status message. The length of the status
|
||
message can vary and thus the size of an OK packet is not fixed.</entry>
|
||
<entry>Used for debugging CS protocol implementation. Note that the total size
|
||
in bytes includes the size of the header packet (4 bytes, see
|
||
protocol overhead).</entry>
|
||
</row>
|
||
<row>
|
||
<entry><literal>packets_received_ok</literal></entry>
|
||
<entry>Connection</entry>
|
||
<entry>Number of MySQL Client Server protocol OK packets received.</entry>
|
||
<entry>Used for debugging CS protocol implementation. Note that the total size
|
||
in bytes includes the size of the header packet (4 bytes, see
|
||
protocol overhead).</entry>
|
||
</row>
|
||
<row>
|
||
<entry><literal>bytes_received_eof_packet</literal></entry>
|
||
<entry>Connection</entry>
|
||
<entry>Total size in bytes of MySQL Client Server protocol EOF packets
|
||
received. EOF can vary in size depending on the server version.
|
||
Also, EOF can transport an error message.</entry>
|
||
<entry>Used for debugging CS protocol implementation. Note that the total size
|
||
in bytes includes the size of the header packet (4 bytes, see
|
||
protocol overhead).</entry>
|
||
</row>
|
||
<row>
|
||
<entry><literal>packets_received_eof</literal></entry>
|
||
<entry>Connection</entry>
|
||
<entry>Number of MySQL Client Server protocol EOF packets. Like with other
|
||
packet statistics the number of packets will be increased even if
|
||
PHP does not receive the expected packet but, for example, an
|
||
error message.</entry>
|
||
<entry>Used for debugging CS protocol implementation. Note that the total size
|
||
in bytes includes the size of the header packet (4 bytes, see
|
||
protocol overhead).</entry>
|
||
</row>
|
||
<row>
|
||
<entry><literal>bytes_received_rset_header_packet</literal></entry>
|
||
<entry>Connection</entry>
|
||
<entry>Total size in bytes of MySQL Client Server protocol result set header
|
||
packets. The size of the packets varies depending on the payload
|
||
(<literal>LOAD LOCAL INFILE</literal>, <literal>INSERT</literal>,
|
||
<literal>UPDATE</literal>, <literal>SELECT</literal>, error
|
||
message).</entry>
|
||
<entry>Used for debugging CS protocol implementation. Note that the total size
|
||
in bytes includes the size of the header packet (4 bytes, see
|
||
protocol overhead).</entry>
|
||
</row>
|
||
<row>
|
||
<entry><literal>packets_received_rset_header</literal></entry>
|
||
<entry>Connection</entry>
|
||
<entry>Number of MySQL Client Server protocol result set header packets.</entry>
|
||
<entry>Used for debugging CS protocol implementation. Note that the total size
|
||
in bytes includes the size of the header packet (4 bytes, see
|
||
protocol overhead).</entry>
|
||
</row>
|
||
<row>
|
||
<entry><literal>bytes_received_rset_field_meta_packet</literal></entry>
|
||
<entry>Connection</entry>
|
||
<entry>Total size in bytes of MySQL Client Server protocol result set meta data
|
||
(field information) packets. Of course the size varies with the
|
||
fields in the result set. The packet may also transport an error
|
||
or an EOF packet in case of COM_LIST_FIELDS.</entry>
|
||
<entry>Only useful for debugging CS protocol implementation. Note that the
|
||
total size in bytes includes the size of the header packet (4
|
||
bytes, see protocol overhead).</entry>
|
||
</row>
|
||
<row>
|
||
<entry><literal>packets_received_rset_field_meta</literal></entry>
|
||
<entry>Connection</entry>
|
||
<entry>Number of MySQL Client Server protocol result set meta data (field
|
||
information) packets.</entry>
|
||
<entry>Only useful for debugging CS protocol implementation. Note that the
|
||
total size in bytes includes the size of the header packet (4
|
||
bytes, see protocol overhead).</entry>
|
||
</row>
|
||
<row>
|
||
<entry><literal>bytes_received_rset_row_packet</literal></entry>
|
||
<entry>Connection</entry>
|
||
<entry>Total size in bytes of MySQL Client Server protocol result set row data
|
||
packets. The packet may also transport an error or an EOF packet.
|
||
You can reverse engineer the number of error and EOF packets by
|
||
subtracting <literal>rows_fetched_from_server_normal</literal>
|
||
and <literal>rows_fetched_from_server_ps</literal> from
|
||
<literal>bytes_received_rset_row_packet</literal>.</entry>
|
||
<entry>Only useful for debugging CS protocol implementation. Note that the
|
||
total size in bytes includes the size of the header packet (4
|
||
bytes, see protocol overhead).</entry>
|
||
</row>
|
||
<row>
|
||
<entry><literal>packets_received_rset_row</literal></entry>
|
||
<entry>Connection</entry>
|
||
<entry>Number of MySQL Client Server protocol result set row data packets and
|
||
their total size in bytes.</entry>
|
||
<entry>Only useful for debugging CS protocol implementation. Note that the
|
||
total size in bytes includes the size of the header packet (4
|
||
bytes, see protocol overhead).</entry>
|
||
</row>
|
||
<row>
|
||
<entry><literal>bytes_received_prepare_response_packet</literal></entry>
|
||
<entry>Connection</entry>
|
||
<entry>Total size in bytes of MySQL Client Server protocol OK for Prepared
|
||
Statement Initialization packets (prepared statement init
|
||
packets). The packet may also transport an error. The packet size
|
||
depends on the MySQL version: 9 bytes with MySQL 4.1 and 12 bytes
|
||
from MySQL 5.0 on. There is no safe way to know how many errors
|
||
happened. You may be able to guess that an error has occurred if,
|
||
for example, you always connect to MySQL 5.0 or newer and,
|
||
<literal>bytes_received_prepare_response_packet</literal> !=
|
||
<literal>packets_received_prepare_response</literal> * 12. See
|
||
also <literal>ps_prepared_never_executed</literal>,
|
||
<literal>ps_prepared_once_executed</literal>.</entry>
|
||
<entry>Only useful for debugging CS protocol implementation. Note that the
|
||
total size in bytes includes the size of the header packet (4
|
||
bytes, see protocol overhead).</entry>
|
||
</row>
|
||
<row>
|
||
<entry><literal>packets_received_prepare_response</literal></entry>
|
||
<entry>Connection</entry>
|
||
<entry>Number of MySQL Client Server protocol OK for Prepared Statement
|
||
Initialization packets (prepared statement init packets).</entry>
|
||
<entry>Only useful for debugging CS protocol implementation. Note that the
|
||
total size in bytes includes the size of the header packet (4
|
||
bytes, see protocol overhead).</entry>
|
||
</row>
|
||
<row>
|
||
<entry><literal>bytes_received_change_user_packet</literal></entry>
|
||
<entry>Connection</entry>
|
||
<entry>Total size in bytes of MySQL Client Server protocol COM_CHANGE_USER
|
||
packets. The packet may also transport an error or EOF.</entry>
|
||
<entry>Only useful for debugging CS protocol implementation. Note that the
|
||
total size in bytes includes the size of the header packet (4
|
||
bytes, see protocol overhead).</entry>
|
||
</row>
|
||
<row>
|
||
<entry><literal>packets_received_change_user</literal></entry>
|
||
<entry>Connection</entry>
|
||
<entry>Number of MySQL Client Server protocol COM_CHANGE_USER packets</entry>
|
||
<entry>Only useful for debugging CS protocol implementation. Note that the
|
||
total size in bytes includes the size of the header packet (4
|
||
bytes, see protocol overhead).</entry>
|
||
</row>
|
||
<row>
|
||
<entry><literal>packets_sent_command</literal></entry>
|
||
<entry>Connection</entry>
|
||
<entry>Number of MySQL Client Server protocol commands sent from PHP to MySQL.
|
||
There is no way to know which specific commands and how many of
|
||
them have been sent. At its best you can use it to check if PHP
|
||
has sent any commands to MySQL to know if you can consider to
|
||
disable MySQL support in your PHP binary. There is also no way to
|
||
reverse engineer the number of errors that may have occurred while
|
||
sending data to MySQL. The only error that is recorded is
|
||
command_buffer_too_small (see below).</entry>
|
||
<entry>Only useful for debugging CS protocol implementation.</entry>
|
||
</row>
|
||
<row>
|
||
<entry><literal>bytes_received_real_data_normal</literal></entry>
|
||
<entry>Connection</entry>
|
||
<entry>Number of bytes of payload fetched by the PHP client from
|
||
<literal>mysqlnd</literal> using the text protocol.</entry>
|
||
<entry>This is the size of the actual data contained in result sets that do not
|
||
originate from prepared statements and which have been fetched by
|
||
the PHP client. Note that although a full result set may have been
|
||
pulled from MySQL by <literal>mysqlnd</literal>, this statistic
|
||
only counts actual data pulled from <literal>mysqlnd</literal> by
|
||
the PHP client. An example of a code sequence that will increase
|
||
the value is as follows:
|
||
<programlisting>
|
||
<![CDATA[
|
||
$mysqli = new mysqli();
|
||
$res = $mysqli->query("SELECT 'abc'");
|
||
$res->fetch_assoc();
|
||
$res->close();
|
||
]]>
|
||
</programlisting>
|
||
<para>
|
||
Every fetch operation will increase the value.
|
||
</para>
|
||
|
||
<para>
|
||
The statistic will not be increased if the result set is only
|
||
buffered on the client, but not fetched, such as in the following
|
||
example:
|
||
</para>
|
||
<programlisting>
|
||
<![CDATA[
|
||
$mysqli = new mysqli();
|
||
$res = $mysqli->query("SELECT 'abc'");
|
||
$res->close();
|
||
]]>
|
||
</programlisting>
|
||
</entry>
|
||
</row>
|
||
<row>
|
||
<entry><literal>bytes_received_real_data_ps</literal></entry>
|
||
<entry>Connection</entry>
|
||
<entry>Number of bytes of the payload fetched by the PHP client from
|
||
<literal>mysqlnd</literal> using the prepared statement protocol.</entry>
|
||
<entry>This is the size of the actual data contained in result sets that
|
||
originate from prepared statements and which has been fetched by
|
||
the PHP client. The value will not be increased if the result set
|
||
is not subsequently read by the PHP client. Note that although a
|
||
full result set may have been pulled from MySQL by
|
||
<literal>mysqlnd</literal>, this statistic only counts actual data
|
||
pulled from <literal>mysqlnd</literal> by the PHP client. See also
|
||
<literal>bytes_received_real_data_normal</literal>.</entry>
|
||
</row>
|
||
</tbody>
|
||
</tgroup>
|
||
</table>
|
||
<para>
|
||
<emphasis role="bold">Result Set</emphasis>
|
||
</para>
|
||
<table xml:id="mysqlnd.stats.results">
|
||
<title>Returned mysqlnd statistics: Result Set</title>
|
||
<tgroup cols="4">
|
||
<colspec colwidth="10*"/>
|
||
<colspec colwidth="10*"/>
|
||
<colspec colwidth="40*"/>
|
||
<colspec colwidth="40*"/>
|
||
<thead>
|
||
<row>
|
||
<entry>Statistic</entry>
|
||
<entry>Scope</entry>
|
||
<entry>Description</entry>
|
||
<entry>Notes</entry>
|
||
</row>
|
||
</thead>
|
||
<tbody>
|
||
<row>
|
||
<entry><literal>result_set_queries</literal></entry>
|
||
<entry>Connection</entry>
|
||
<entry>Number of queries that have generated a result set. Examples of queries
|
||
that generate a result set: <literal>SELECT</literal>,
|
||
<literal>SHOW</literal>. The statistic will not be incremented if
|
||
there is an error reading the result set header packet from the
|
||
line.</entry>
|
||
<entry>You may use it as an indirect measure for the number of queries PHP has
|
||
sent to MySQL, for example, to identify a client that causes a
|
||
high database load.</entry>
|
||
</row>
|
||
<row>
|
||
<entry><literal>non_result_set_queries</literal></entry>
|
||
<entry>Connection</entry>
|
||
<entry>Number of queries that did not generate a result set. Examples of
|
||
queries that do not generate a result set:
|
||
<literal>INSERT</literal>, <literal>UPDATE</literal>,
|
||
<literal>LOAD DATA</literal>. The
|
||
statistic will not be incremented if there is an error reading the
|
||
result set header packet from the line.</entry>
|
||
<entry>You may use it as an indirect measure for the number of queries PHP has
|
||
sent to MySQL, for example, to identify a client that causes a
|
||
high database load.</entry>
|
||
</row>
|
||
<row>
|
||
<entry><literal>no_index_used</literal></entry>
|
||
<entry>Connection</entry>
|
||
<entry>Number of queries that have generated a result set but did not use an
|
||
index (see also mysqld start option
|
||
–log-queries-not-using-indexes). If you want these queries to be
|
||
reported you can use mysqli_report(MYSQLI_REPORT_INDEX) to make
|
||
ext/mysqli throw an exception. If you prefer a warning instead of
|
||
an exception use mysqli_report(MYSQLI_REPORT_INDEX ^
|
||
MYSQLI_REPORT_STRICT).</entry>
|
||
<entry></entry>
|
||
</row>
|
||
<row>
|
||
<entry><literal>bad_index_used</literal></entry>
|
||
<entry>Connection</entry>
|
||
<entry>Number of queries that have generated a result set and did not use a
|
||
good index (see also mysqld start option –log-slow-queries).</entry>
|
||
<entry>If you want these queries to be reported you can use
|
||
mysqli_report(MYSQLI_REPORT_INDEX) to make ext/mysqli throw an
|
||
exception. If you prefer a warning instead of an exception use
|
||
mysqli_report(MYSQLI_REPORT_INDEX ^ MYSQLI_REPORT_STRICT)</entry>
|
||
</row>
|
||
<row>
|
||
<entry><literal>slow_queries</literal></entry>
|
||
<entry>Connection</entry>
|
||
<entry>SQL statements that took more than <literal>long_query_time</literal>
|
||
seconds to execute and required at least
|
||
<literal>min_examined_row_limit</literal> rows to be examined.</entry>
|
||
<entry>Not reported through <function>mysqli_report</function></entry>
|
||
</row>
|
||
<row>
|
||
<entry><literal>buffered_sets</literal></entry>
|
||
<entry>Connection</entry>
|
||
<entry>Number of buffered result sets returned by <quote>normal</quote>
|
||
queries. <quote>Normal</quote> means <quote>not prepared
|
||
statement</quote> in the following notes.</entry>
|
||
<entry>Examples of API calls that will buffer result sets on the client:
|
||
<function>mysql_query</function>,
|
||
<function>mysqli_query</function>,
|
||
<function>mysqli_store_result</function>,
|
||
<function>mysqli_stmt_get_result</function>. Buffering result sets
|
||
on the client ensures that server resources are freed as soon as
|
||
possible and it makes result set scrolling easier. The downside is
|
||
the additional memory consumption on the client for buffering
|
||
data. Note that mysqlnd (unlike the MySQL Client Library) respects
|
||
the PHP memory limit because it uses PHP internal memory
|
||
management functions to allocate memory. This is also the reason
|
||
why <function>memory_get_usage</function> reports a higher memory
|
||
consumption when using mysqlnd instead of the MySQL Client
|
||
Library. <function>memory_get_usage</function> does not measure
|
||
the memory consumption of the MySQL Client Library at all because
|
||
the MySQL Client Library does not use PHP internal memory
|
||
management functions monitored by the function!</entry>
|
||
</row>
|
||
<row>
|
||
<entry><literal>unbuffered_sets</literal></entry>
|
||
<entry>Connection</entry>
|
||
<entry>Number of unbuffered result sets returned by normal (non prepared
|
||
statement) queries.</entry>
|
||
<entry>Examples of API calls that will not buffer result sets on the client:
|
||
<function>mysqli_use_result</function></entry>
|
||
</row>
|
||
<row>
|
||
<entry><literal>ps_buffered_sets</literal></entry>
|
||
<entry>Connection</entry>
|
||
<entry>Number of buffered result sets returned by prepared statements. By
|
||
default prepared statements are unbuffered.</entry>
|
||
<entry>Examples of API calls that will buffer result sets on the client:
|
||
<literal>mysqli_stmt_store_result</literal></entry>
|
||
</row>
|
||
<row>
|
||
<entry><literal>ps_unbuffered_sets</literal></entry>
|
||
<entry>Connection</entry>
|
||
<entry>Number of unbuffered result sets returned by prepared statements.</entry>
|
||
<entry>By default prepared statements are unbuffered.</entry>
|
||
</row>
|
||
<row>
|
||
<entry><literal>flushed_normal_sets</literal></entry>
|
||
<entry>Connection</entry>
|
||
<entry>Number of result sets from normal (non prepared statement) queries with
|
||
unread data which have been flushed silently for you. Flushing
|
||
happens only with unbuffered result sets.</entry>
|
||
<entry>Unbuffered result sets must be fetched completely before a new query can
|
||
be run on the connection otherwise MySQL will throw an error. If
|
||
the application does not fetch all rows from an unbuffered result
|
||
set, mysqlnd does implicitly fetch the result set to clear the
|
||
line. See also <literal>rows_skipped_normal</literal>,
|
||
<literal>rows_skipped_ps</literal>. Some possible causes for an
|
||
implicit flush:
|
||
<itemizedlist>
|
||
<listitem>
|
||
<para>
|
||
Faulty client application
|
||
</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>
|
||
Client stopped reading after it found what it was looking for
|
||
but has made MySQL calculate more records than needed
|
||
</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>
|
||
Client application has stopped unexpectedly
|
||
</para>
|
||
</listitem>
|
||
</itemizedlist></entry>
|
||
</row>
|
||
<row>
|
||
<entry><literal>flushed_ps_sets</literal></entry>
|
||
<entry>Connection</entry>
|
||
<entry>Number of result sets from prepared statements with unread data which
|
||
have been flushed silently for you. Flushing happens only with
|
||
unbuffered result sets.</entry>
|
||
<entry>Unbuffered result sets must be fetched completely before a new query can
|
||
be run on the connection otherwise MySQL will throw an error. If
|
||
the application does not fetch all rows from an unbuffered result
|
||
set, mysqlnd does implicitly fetch the result set to clear the
|
||
line. See also <literal>rows_skipped_normal</literal>,
|
||
<literal>rows_skipped_ps</literal>. Some possible causes for an
|
||
implicit flush:
|
||
<itemizedlist>
|
||
<listitem>
|
||
<para>
|
||
Faulty client application
|
||
</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>
|
||
Client stopped reading after it found what it was looking for
|
||
but has made MySQL calculate more records than needed
|
||
</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>
|
||
Client application has stopped unexpectedly
|
||
</para>
|
||
</listitem>
|
||
</itemizedlist></entry>
|
||
</row>
|
||
<row>
|
||
<entry><literal>ps_prepared_never_executed</literal></entry>
|
||
<entry>Connection</entry>
|
||
<entry>Number of statements prepared but never executed.</entry>
|
||
<entry>Prepared statements occupy server resources. You should not prepare a
|
||
statement if you do not plan to execute it.</entry>
|
||
</row>
|
||
<row>
|
||
<entry><literal>ps_prepared_once_executed</literal></entry>
|
||
<entry>Connection</entry>
|
||
<entry>Number of prepared statements executed only one.</entry>
|
||
<entry>One of the ideas behind prepared statements is that the same query gets
|
||
executed over and over again (with different parameters) and some
|
||
parsing and other preparation work can be saved, if statement
|
||
execution is split up in separate prepare and execute stages. The
|
||
idea is to prepare once and <quote>cache</quote> results, for
|
||
example, the parse tree to be reused during multiple statement
|
||
executions. If you execute a prepared statement only once the two
|
||
stage processing can be inefficient compared to
|
||
<quote>normal</quote> queries because all the caching means extra
|
||
work and it takes (limited) server resources to hold the cached
|
||
information. Consequently, prepared statements that are executed
|
||
only once may cause performance hurts.</entry>
|
||
</row>
|
||
<row>
|
||
<entry><literal>rows_fetched_from_server_normal</literal>,
|
||
<literal>rows_fetched_from_server_ps</literal></entry>
|
||
<entry>Connection</entry>
|
||
<entry>Total number of result set rows successfully fetched from MySQL
|
||
regardless if the client application has consumed them or not.
|
||
Some of the rows may not have been fetched by the client
|
||
application but have been flushed implicitly.</entry>
|
||
<entry>See also <literal>packets_received_rset_row</literal></entry>
|
||
</row>
|
||
<row>
|
||
<entry><literal>rows_buffered_from_client_normal</literal>,
|
||
<literal>rows_buffered_from_client_ps</literal></entry>
|
||
<entry>Connection</entry>
|
||
<entry>Total number of successfully buffered rows originating from a "normal"
|
||
query or a prepared statement. This is the number of rows that
|
||
have been fetched from MySQL and buffered on client. Note that
|
||
there are two distinct statistics on rows that have been buffered
|
||
(MySQL to mysqlnd internal buffer) and buffered rows that have
|
||
been fetched by the client application (mysqlnd internal buffer to
|
||
client application). If the number of buffered rows is higher than
|
||
the number of fetched buffered rows it can mean that the client
|
||
application runs queries that cause larger result sets than needed
|
||
resulting in rows not read by the client.</entry>
|
||
<entry>Examples of queries that will buffer results:
|
||
<function>mysqli_query</function>,
|
||
<function>mysqli_store_result</function></entry>
|
||
</row>
|
||
<row>
|
||
<entry><literal>rows_fetched_from_client_normal_buffered</literal>,
|
||
<literal>rows_fetched_from_client_ps_buffered</literal></entry>
|
||
<entry>Connection</entry>
|
||
<entry>Total number of rows fetched by the client from a buffered result set
|
||
created by a normal query or a prepared statement.</entry>
|
||
<entry></entry>
|
||
</row>
|
||
<row>
|
||
<entry><literal>rows_fetched_from_client_normal_unbuffered</literal>,
|
||
<literal>rows_fetched_from_client_ps_unbuffered</literal></entry>
|
||
<entry>Connection</entry>
|
||
<entry>Total number of rows fetched by the client from a unbuffered result set
|
||
created by a "normal" query or a prepared statement.</entry>
|
||
<entry></entry>
|
||
</row>
|
||
<row>
|
||
<entry><literal>rows_fetched_from_client_ps_cursor</literal></entry>
|
||
<entry>Connection</entry>
|
||
<entry>Total number of rows fetch by the client from a cursor created by a
|
||
prepared statement.</entry>
|
||
<entry></entry>
|
||
</row>
|
||
<row>
|
||
<entry><literal>rows_skipped_normal</literal>,
|
||
<literal>rows_skipped_ps</literal></entry>
|
||
<entry>Connection</entry>
|
||
<entry>Reserved for future use (currently not supported)</entry>
|
||
<entry></entry>
|
||
</row>
|
||
<row>
|
||
<entry><literal>copy_on_write_saved</literal>,
|
||
<literal>copy_on_write_performed</literal></entry>
|
||
<entry>Process</entry>
|
||
<entry>With mysqlnd, variables returned by the extensions point into mysqlnd
|
||
internal network result buffers. If you do not change the
|
||
variables, fetched data will be kept only once in memory. If you
|
||
change the variables, mysqlnd has to perform a copy-on-write to
|
||
protect the internal network result buffers from being changed.
|
||
With the MySQL Client Library you always hold fetched data twice
|
||
in memory. Once in the internal MySQL Client Library buffers and
|
||
once in the variables returned by the extensions. In theory
|
||
mysqlnd can save up to 40% memory. However, note that the memory
|
||
saving cannot be measured using
|
||
<function>memory_get_usage</function>.</entry>
|
||
<entry></entry>
|
||
</row>
|
||
<row>
|
||
<entry><literal>explicit_free_result</literal>,
|
||
<literal>implicit_free_result</literal></entry>
|
||
<entry>Connection, Process (only during prepared statement cleanup)</entry>
|
||
<entry>Total number of freed result sets.</entry>
|
||
<entry>The free is always considered explicit but for result sets created by an
|
||
init command, for example,
|
||
<literal>mysqli_options(MYSQLI_INIT_COMMAND , ...)</literal></entry>
|
||
</row>
|
||
<row>
|
||
<entry><literal>proto_text_fetched_null</literal>,
|
||
<literal>proto_text_fetched_bit</literal>,
|
||
<literal>proto_text_fetched_tinyint</literal>
|
||
<literal>proto_text_fetched_short</literal>,
|
||
<literal>proto_text_fetched_int24</literal>,
|
||
<literal>proto_text_fetched_int</literal>
|
||
<literal>proto_text_fetched_bigint</literal>,
|
||
<literal>proto_text_fetched_decimal</literal>,
|
||
<literal>proto_text_fetched_float</literal>
|
||
<literal>proto_text_fetched_double</literal>,
|
||
<literal>proto_text_fetched_date</literal>,
|
||
<literal>proto_text_fetched_year</literal>
|
||
<literal>proto_text_fetched_time</literal>,
|
||
<literal>proto_text_fetched_datetime</literal>,
|
||
<literal>proto_text_fetched_timestamp</literal>
|
||
<literal>proto_text_fetched_string</literal>,
|
||
<literal>proto_text_fetched_blob</literal>,
|
||
<literal>proto_text_fetched_enum</literal>
|
||
<literal>proto_text_fetched_set</literal>,
|
||
<literal>proto_text_fetched_geometry</literal>,
|
||
<literal>proto_text_fetched_other</literal></entry>
|
||
<entry>Connection</entry>
|
||
<entry>Total number of columns of a certain type fetched from a normal query
|
||
(MySQL text protocol).</entry>
|
||
<entry>Mapping from C API / MySQL meta data type to statistics name:
|
||
<itemizedlist>
|
||
<listitem>
|
||
<para>
|
||
<literal>MYSQL_TYPE_NULL</literal> - proto_text_fetched_null
|
||
</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>
|
||
<literal>MYSQL_TYPE_BIT</literal> - proto_text_fetched_bit
|
||
</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>
|
||
<literal>MYSQL_TYPE_TINY</literal> - proto_text_fetched_tinyint
|
||
</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>
|
||
<literal>MYSQL_TYPE_SHORT</literal> - proto_text_fetched_short
|
||
</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>
|
||
<literal>MYSQL_TYPE_INT24</literal> - proto_text_fetched_int24
|
||
</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>
|
||
<literal>MYSQL_TYPE_LONG</literal> - proto_text_fetched_int
|
||
</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>
|
||
<literal>MYSQL_TYPE_LONGLONG</literal> -
|
||
proto_text_fetched_bigint
|
||
</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>
|
||
<literal>MYSQL_TYPE_DECIMAL</literal>,
|
||
<literal>MYSQL_TYPE_NEWDECIMAL</literal> -
|
||
proto_text_fetched_decimal
|
||
</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>
|
||
<literal>MYSQL_TYPE_FLOAT</literal> - proto_text_fetched_float
|
||
</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>
|
||
<literal>MYSQL_TYPE_DOUBLE</literal> -
|
||
proto_text_fetched_double
|
||
</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>
|
||
<literal>MYSQL_TYPE_DATE</literal>,
|
||
<literal>MYSQL_TYPE_NEWDATE</literal> - proto_text_fetched_date
|
||
</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>
|
||
<literal>MYSQL_TYPE_YEAR</literal> - proto_text_fetched_year
|
||
</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>
|
||
<literal>MYSQL_TYPE_TIME</literal> - proto_text_fetched_time
|
||
</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>
|
||
<literal>MYSQL_TYPE_DATETIME</literal> -
|
||
proto_text_fetched_datetime
|
||
</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>
|
||
<literal>MYSQL_TYPE_TIMESTAMP</literal> -
|
||
proto_text_fetched_timestamp
|
||
</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>
|
||
<literal>MYSQL_TYPE_STRING</literal>,
|
||
<literal>MYSQL_TYPE_VARSTRING</literal>,
|
||
<literal>MYSQL_TYPE_VARCHAR</literal> -
|
||
proto_text_fetched_string
|
||
</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>
|
||
<literal>MYSQL_TYPE_TINY_BLOB</literal>,
|
||
<literal>MYSQL_TYPE_MEDIUM_BLOB</literal>,
|
||
<literal>MYSQL_TYPE_LONG_BLOB</literal>,
|
||
<literal>MYSQL_TYPE_BLOB</literal> - proto_text_fetched_blob
|
||
</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>
|
||
<literal>MYSQL_TYPE_ENUM</literal> - proto_text_fetched_enum
|
||
</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>
|
||
<literal>MYSQL_TYPE_SET</literal> - proto_text_fetched_set
|
||
</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>
|
||
<literal>MYSQL_TYPE_GEOMETRY</literal> -
|
||
proto_text_fetched_geometry
|
||
</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>
|
||
Any <literal>MYSQL_TYPE_*</literal> not listed before (there
|
||
should be none) - proto_text_fetched_other
|
||
</para>
|
||
</listitem>
|
||
</itemizedlist>
|
||
<para>
|
||
Note that the MYSQL_*-type constants may not be associated with
|
||
the very same SQL column types in every version of MySQL.
|
||
</para></entry>
|
||
</row>
|
||
<row>
|
||
<entry><literal>proto_binary_fetched_null</literal>,
|
||
<literal>proto_binary_fetched_bit</literal>,
|
||
<literal>proto_binary_fetched_tinyint</literal>
|
||
<literal>proto_binary_fetched_short</literal>,
|
||
<literal>proto_binary_fetched_int24</literal>,
|
||
<literal>proto_binary_fetched_int</literal>,
|
||
<literal>proto_binary_fetched_bigint</literal>,
|
||
<literal>proto_binary_fetched_decimal</literal>,
|
||
<literal>proto_binary_fetched_float</literal>,
|
||
<literal>proto_binary_fetched_double</literal>,
|
||
<literal>proto_binary_fetched_date</literal>,
|
||
<literal>proto_binary_fetched_year</literal>,
|
||
<literal>proto_binary_fetched_time</literal>,
|
||
<literal>proto_binary_fetched_datetime</literal>,
|
||
<literal>proto_binary_fetched_timestamp</literal>,
|
||
<literal>proto_binary_fetched_string</literal>,
|
||
<literal>proto_binary_fetched_blob</literal>,
|
||
<literal>proto_binary_fetched_enum</literal>,
|
||
<literal>proto_binary_fetched_set</literal>,
|
||
<literal>proto_binary_fetched_geometry</literal>,
|
||
<literal>proto_binary_fetched_other</literal></entry>
|
||
<entry>Connection</entry>
|
||
<entry>Total number of columns of a certain type fetched from a prepared
|
||
statement (MySQL binary protocol).</entry>
|
||
<entry>For type mapping see <literal>proto_text_*</literal> described in the
|
||
preceding text.</entry>
|
||
</row>
|
||
</tbody>
|
||
</tgroup>
|
||
</table>
|
||
<table xml:id="mysqlnd.stats.connection">
|
||
<title>Returned mysqlnd statistics: Connection</title>
|
||
<tgroup cols="4">
|
||
<colspec colwidth="10*"/>
|
||
<colspec colwidth="10*"/>
|
||
<colspec colwidth="40*"/>
|
||
<colspec colwidth="40*"/>
|
||
<thead>
|
||
<row>
|
||
<entry>Statistic</entry>
|
||
<entry>Scope</entry>
|
||
<entry>Description</entry>
|
||
<entry>Notes</entry>
|
||
</row>
|
||
</thead>
|
||
<tbody>
|
||
<row>
|
||
<entry><literal>connect_success</literal>, <literal>connect_failure</literal></entry>
|
||
<entry>Connection</entry>
|
||
<entry>Total number of successful / failed connection attempt.</entry>
|
||
<entry>Reused connections and all other kinds of connections are included.</entry>
|
||
</row>
|
||
<row>
|
||
<entry><literal>reconnect</literal></entry>
|
||
<entry>Process</entry>
|
||
<entry>Total number of (real_)connect attempts made on an already opened
|
||
connection handle.</entry>
|
||
<entry>The code sequence <literal>$link = new mysqli(...);
|
||
$link->real_connect(...)</literal> will cause a reconnect. But
|
||
<literal>$link = new mysqli(...); $link->connect(...)</literal>
|
||
will not because <literal>$link->connect(...)</literal> will
|
||
explicitly close the existing connection before a new connection
|
||
is established.</entry>
|
||
</row>
|
||
<row>
|
||
<entry><literal>pconnect_success</literal></entry>
|
||
<entry>Connection</entry>
|
||
<entry>Total number of successful persistent connection attempts.</entry>
|
||
<entry>Note that <literal>connect_success</literal> holds the sum of successful
|
||
persistent and non-persistent connection attempts. The number of
|
||
successful non-persistent connection attempts is
|
||
<literal>connect_success</literal> -
|
||
<literal>pconnect_success</literal>.</entry>
|
||
</row>
|
||
<row>
|
||
<entry><literal>active_connections</literal></entry>
|
||
<entry>Connection</entry>
|
||
<entry>Total number of active persistent and non-persistent connections.</entry>
|
||
<entry></entry>
|
||
</row>
|
||
<row>
|
||
<entry><literal>active_persistent_connections</literal></entry>
|
||
<entry>Connection</entry>
|
||
<entry>Total number of active persistent connections.</entry>
|
||
<entry>The total number of active non-persistent connections is
|
||
<literal>active_connections</literal> -
|
||
<literal>active_persistent_connections</literal>.</entry>
|
||
</row>
|
||
<row>
|
||
<entry><literal>explicit_close</literal></entry>
|
||
<entry>Connection</entry>
|
||
<entry>Total number of explicitly closed connections (ext/mysqli only).</entry>
|
||
<entry>Examples of code snippets that cause an explicit close :
|
||
<programlisting>
|
||
<![CDATA[
|
||
$link = new mysqli(...); $link->close(...)
|
||
$link = new mysqli(...); $link->connect(...)
|
||
]]>
|
||
</programlisting></entry>
|
||
</row>
|
||
<row>
|
||
<entry><literal>implicit_close</literal></entry>
|
||
<entry>Connection</entry>
|
||
<entry>Total number of implicitly closed connections (ext/mysqli only).</entry>
|
||
<entry>Examples of code snippets that cause an implicit close :
|
||
<itemizedlist>
|
||
<listitem>
|
||
<para>
|
||
<literal>$link = new mysqli(...);
|
||
$link->real_connect(...)</literal>
|
||
</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>
|
||
<literal>unset($link)</literal>
|
||
</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>
|
||
Persistent connection: pooled connection has been created with
|
||
real_connect and there may be unknown options set - close
|
||
implicitly to avoid returning a connection with unknown options
|
||
</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>
|
||
Persistent connection: ping/change_user fails and ext/mysqli
|
||
closes the connection
|
||
</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>
|
||
end of script execution: close connections that have not been
|
||
closed by the user
|
||
</para>
|
||
</listitem>
|
||
</itemizedlist></entry>
|
||
</row>
|
||
<row>
|
||
<entry><literal>disconnect_close</literal></entry>
|
||
<entry>Connection</entry>
|
||
<entry>Connection failures indicated by the C API call
|
||
<function>mysql_real_connect</function> during an attempt to
|
||
establish a connection.</entry>
|
||
<entry>It is called <literal>disconnect_close</literal> because the connection
|
||
handle passed to the C API call will be closed.</entry>
|
||
</row>
|
||
<row>
|
||
<entry><literal>in_middle_of_command_close</literal></entry>
|
||
<entry>Process</entry>
|
||
<entry>A connection has been closed in the middle of a command execution
|
||
(outstanding result sets not fetched, after sending a query and
|
||
before retrieving an answer, while fetching data, while
|
||
transferring data with LOAD DATA).</entry>
|
||
<entry>Unless you use asynchronous queries this should only happen if your
|
||
script stops unexpectedly and PHP shuts down the connections for
|
||
you.</entry>
|
||
</row>
|
||
<row>
|
||
<entry><literal>init_command_executed_count</literal></entry>
|
||
<entry>Connection</entry>
|
||
<entry>Total number of init command executions, for example,
|
||
<literal>mysqli_options(MYSQLI_INIT_COMMAND , ...)</literal>.</entry>
|
||
<entry>The number of successful executions is
|
||
<literal>init_command_executed_count</literal> -
|
||
<literal>init_command_failed_count</literal>.</entry>
|
||
</row>
|
||
<row>
|
||
<entry><literal>init_command_failed_count</literal></entry>
|
||
<entry>Connection</entry>
|
||
<entry>Total number of failed init commands.</entry>
|
||
<entry></entry>
|
||
</row>
|
||
</tbody>
|
||
</tgroup>
|
||
</table>
|
||
<table xml:id="mysqlnd.stats.com">
|
||
<title>Returned mysqlnd statistics: COM_* Command</title>
|
||
<tgroup cols="4">
|
||
<colspec colwidth="10*"/>
|
||
<colspec colwidth="10*"/>
|
||
<colspec colwidth="40*"/>
|
||
<colspec colwidth="40*"/>
|
||
<thead>
|
||
<row>
|
||
<entry>Statistic</entry>
|
||
<entry>Scope</entry>
|
||
<entry>Description</entry>
|
||
<entry>Notes</entry>
|
||
</row>
|
||
</thead>
|
||
<tbody>
|
||
<row>
|
||
<entry><literal>com_quit</literal>, <literal>com_init_db</literal>,
|
||
<literal>com_query</literal>, <literal>com_field_list</literal>,
|
||
<literal>com_create_db</literal>, <literal>com_drop_db</literal>,
|
||
<literal>com_refresh</literal>, <literal>com_shutdown</literal>,
|
||
<literal>com_statistics</literal>,
|
||
<literal>com_process_info</literal>,
|
||
<literal>com_connect</literal>,
|
||
<literal>com_process_kill</literal>, <literal>com_debug</literal>,
|
||
<literal>com_ping</literal>, <literal>com_time</literal>,
|
||
<literal>com_delayed_insert</literal>,
|
||
<literal>com_change_user</literal>,
|
||
<literal>com_binlog_dump</literal>,
|
||
<literal>com_table_dump</literal>,
|
||
<literal>com_connect_out</literal>,
|
||
<literal>com_register_slave</literal>,
|
||
<literal>com_stmt_prepare</literal>,
|
||
<literal>com_stmt_execute</literal>,
|
||
<literal>com_stmt_send_long_data</literal>,
|
||
<literal>com_stmt_close</literal>,
|
||
<literal>com_stmt_reset</literal>,
|
||
<literal>com_stmt_set_option</literal>,
|
||
<literal>com_stmt_fetch</literal>, <literal>com_daemon</literal></entry>
|
||
<entry>Connection</entry>
|
||
<entry>Total number of attempts to send a certain COM_* command from PHP to
|
||
MySQL.</entry>
|
||
<entry><para>
|
||
The statistics are incremented after checking the line and
|
||
immediately before sending the corresponding MySQL client server
|
||
protocol packet. If mysqlnd fails to send the packet over the
|
||
wire the statistics will not be decremented. In case of a failure
|
||
mysqlnd emits a PHP warning <quote>Error while sending %s packet.
|
||
PID=%d.</quote>
|
||
</para>
|
||
|
||
<para>
|
||
Usage examples:
|
||
</para>
|
||
<itemizedlist>
|
||
<listitem>
|
||
<para>
|
||
Check if PHP sends certain commands to MySQL, for example,
|
||
check if a client sends <literal>COM_PROCESS_KILL</literal>
|
||
</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>
|
||
Calculate the average number of prepared statement executions
|
||
by comparing <literal>COM_EXECUTE</literal> with
|
||
<literal>COM_PREPARE</literal>
|
||
</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>
|
||
Check if PHP has run any non-prepared SQL statements by
|
||
checking if <literal>COM_QUERY</literal> is zero
|
||
</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>
|
||
Identify PHP scripts that run an excessive number of SQL
|
||
statements by checking <literal>COM_QUERY</literal> and
|
||
<literal>COM_EXECUTE</literal>
|
||
</para>
|
||
</listitem>
|
||
</itemizedlist></entry>
|
||
</row>
|
||
</tbody>
|
||
</tgroup>
|
||
</table>
|
||
<para>
|
||
<emphasis role="bold">Miscellaneous</emphasis>
|
||
</para>
|
||
<table xml:id="mysqlnd.stats.misc">
|
||
<title>Returned mysqlnd statistics: Miscellaneous</title>
|
||
<tgroup cols="4">
|
||
<colspec colwidth="10*"/>
|
||
<colspec colwidth="10*"/>
|
||
<colspec colwidth="40*"/>
|
||
<colspec colwidth="40*"/>
|
||
<thead>
|
||
<row>
|
||
<entry>Statistic</entry>
|
||
<entry>Scope</entry>
|
||
<entry>Description</entry>
|
||
<entry>Notes</entry>
|
||
</row>
|
||
</thead>
|
||
<tbody>
|
||
<row>
|
||
<entry><literal>explicit_stmt_close</literal>,
|
||
<literal>implicit_stmt_close</literal></entry>
|
||
<entry>Process</entry>
|
||
<entry>Total number of close prepared statements.</entry>
|
||
<entry>A close is always considered explicit but for a failed prepare.</entry>
|
||
</row>
|
||
<row>
|
||
<entry><literal>mem_emalloc_count</literal>,
|
||
<literal>mem_emalloc_ammount</literal>,
|
||
<literal>mem_ecalloc_count</literal>,
|
||
<literal>mem_ecalloc_ammount</literal>,
|
||
<literal>mem_erealloc_count</literal>,
|
||
<literal>mem_erealloc_ammount</literal>,
|
||
<literal>mem_efree_count</literal>,
|
||
<literal>mem_malloc_count</literal>,
|
||
<literal>mem_malloc_ammount</literal>,
|
||
<literal>mem_calloc_count</literal>,
|
||
<literal>mem_calloc_ammount</literal>,
|
||
<literal>mem_realloc_count</literal>,
|
||
<literal>mem_realloc_ammount</literal>,
|
||
<literal>mem_free_count</literal></entry>
|
||
<entry>Process</entry>
|
||
<entry>Memory management calls.</entry>
|
||
<entry>Development only.</entry>
|
||
</row>
|
||
<row>
|
||
<entry><literal>command_buffer_too_small</literal></entry>
|
||
<entry>Connection</entry>
|
||
<entry>Number of network command buffer extensions while sending commands from
|
||
PHP to MySQL.</entry>
|
||
<entry><para>
|
||
mysqlnd allocates an internal command/network buffer of
|
||
<literal>mysqlnd.net_cmd_buffer_size</literal>
|
||
(<filename>php.ini</filename>) bytes for every connection. If a
|
||
MySQL Client Server protocol command, for example,
|
||
<literal>COM_QUERY</literal> (normal query), does not fit into
|
||
the buffer, mysqlnd will grow the buffer to what is needed for
|
||
sending the command. Whenever the buffer gets extended for one
|
||
connection <literal>command_buffer_too_small</literal> will be
|
||
incremented by one.
|
||
</para>
|
||
|
||
<para>
|
||
If mysqlnd has to grow the buffer beyond its initial size of
|
||
<literal>mysqlnd.net_cmd_buffer_size</literal>
|
||
(<filename>php.ini</filename>) bytes for almost every connection,
|
||
you should consider to increase the default size to avoid
|
||
re-allocations.
|
||
</para>
|
||
|
||
<para>
|
||
The default buffer size is 4096 bytes, which is the smallest value possible. The default can
|
||
changed either through the <filename>php.ini</filename> setting
|
||
<literal>mysqlnd.net_cmd_buffer_size</literal> or using
|
||
<literal>mysqli_options(MYSQLI_OPT_NET_CMD_BUFFER_SIZE, int
|
||
size)</literal>.
|
||
</para></entry>
|
||
</row>
|
||
<row>
|
||
<entry><literal>connection_reused</literal></entry>
|
||
<entry></entry>
|
||
<entry></entry>
|
||
<entry></entry>
|
||
</row>
|
||
</tbody>
|
||
</tgroup>
|
||
</table>
|
||
</chapter>
|
||
<!-- Keep this comment at the end of the file
|
||
Local variables:
|
||
mode: sgml
|
||
sgml-omittag:t
|
||
sgml-shorttag:t
|
||
sgml-minimize-attributes:nil
|
||
sgml-always-quote-attributes:t
|
||
sgml-indent-step:1
|
||
sgml-indent-data:t
|
||
indent-tabs-mode:nil
|
||
sgml-parent-document:nil
|
||
sgml-default-dtd-file:"~/.phpdoc/manual.ced"
|
||
sgml-exposed-tags:nil
|
||
sgml-local-catalogs:nil
|
||
sgml-local-ecat-files:nil
|
||
End:
|
||
vim600: syn=xml fen fdm=syntax fdl=2 si
|
||
vim: et tw=78 syn=sgml
|
||
vi: ts=1 sw=1
|
||
-->
|