On slow query logging included in server-based RDBMS:
There can and will be storage backends not based on SQL DBs. This issue proposes a generic solution.
A single operation can execute a lot of SQL queries, cumulative timing information is also useful.
Proposed solution
In config:
imap ... {
...
time_storage_calls on
slow_call_threshold 250ms
}
In log:
imap/perftrace: KEY (ARGS...) took TIME
Where KEY is arbitrary string (usually corresponding storage method name), ARGS is context information (usually method arguments) and TIME is duration of method execution.
Message is logged only if TIME is bigger than slow_call_threshold specified in config.
The log message format is well-defined and machine-readable. It is easy to get trace messages from the log file because they have a separate message prefix (modulename/perftrace).
Same tracing approach can be applied to other operations (such as authentication, SMTP delivery, etc).
Use case
Useful for performance analysis.
On slow query logging included in server-based RDBMS:
Proposed solution
In config:
In log:
Where KEY is arbitrary string (usually corresponding storage method name), ARGS is context information (usually method arguments) and TIME is duration of method execution. Message is logged only if TIME is bigger than slow_call_threshold specified in config.
The log message format is well-defined and machine-readable. It is easy to get trace messages from the log file because they have a separate message prefix (
modulename/perftrace
).Same tracing approach can be applied to other operations (such as authentication, SMTP delivery, etc).