Identifying Slow Transactions
The
Content Store
measures the time taken to execute every SQL statement. The
escenic-admin
application's Performance
summary option (see
Performance Summary) displays a page
of performance data that includes the average and peak access times
for database engine queries and updates:
Database Engine Queries: Since last sample: 2 db queries; effective 0.00Hz; average 4ms; peak 6ms; load 0.00 (delta -0.00); 0 failures; Total: 44 db queries; average 32ms. Database Engine Updates: Since last sample: 862 db transactions; effective 1.58Hz; average 2ms; peak 27ms; load 0.00 (delta -0.00); 0 failures; Total: 14148 db transactions; average 8ms.
These figures give you some idea of how the database is performing: a well-performing database will usually have an average access time of around 10 milliseconds for both queries and updates.
If a database operation takes more than 10 seconds (10,000 milliseconds), the Content Store logs the transaction with an ERROR message in the log. The message contains information about the internal Content Store transaction being performed, and may in some cases contain the actual SQL query being executed. If your database regularly has peaks of over 10 seconds, you should look in the log file to see what kinds of transactions are causing the problems.
The 10 second threshold for logging database transactions as errors is
not fixed: you can set the threshold higher or lower by configuring
the /neo/io/managers/ContentManager
component. To
change the error threshold for read transactions, set the
readThreshold
property. To change the error
threshold for write transactions, set the
updateThreshold
property.
You can reset these properties at run time using the
escenic-admin
application's Component
browser option (see
Component Browser). In this way you
can easily set the properties to catch the peak access times currently
being reported by the Performance summary option
and find out what operations are causing the problems.