When you are looking to improve the performance of your Drupal website it is always worth taking a look at the watchdog log, found at Admin > Reports > Recent Log Messages.
In a properly functioning Drupal site this report should be informing the administrator of significant events and encouraging them to take appropriate actions when necessary. Typically you would not expect normal page views and interactions to generate much, or any, activity in the watchog log.
However, that is often not the case. Frequently I have been asked to look at slow Drupal installations where I see an awful lot of entries similar to these for regular page views:
Warning: XXX() expects parameter 1 to be XXX, boolean given in XXX()
Notice: Undefined property: XXX::XXX in XXX()
The reason this is a problem is that every entry in the watchdog log is the result of database INSERT. Each INSERT requires a round trip to the database and data must be written somewhere. This slows down the page loading process, and also consumes server resources that are therefore not available for another process, perhaps to deliver a page to another user.
This problem is most severe when the offending code exists inside some kind of loop. For example, imaging you are using the Views module to build a page that outputs 100 rows of data. You have a row template file that contains the code causing the watchdog entries. That means you will see 100 watchdog entries everytime any time a user requests this page, assuming it is not being served from a cache.
Most of the time this is very simple to fix by making the PHP code a little more robust, for example by checking that object properties exist before attempting to access them using something like isset() or empty().
- Log in to post comments
Comments
Async DB connection to the rescue
Permalink Submitted by mikeytown2 on Mon, 01/11/2016 - 23:05.
The Asynchronous Prefetch Database Query Cache module will use an async write to the DB on watchdog inserts - https://www.drupal.org/project/apdqc
Fixing notices is the best though, this query can help to identify the worst offenders first - http://groups.drupal.org/node/170339
This is interesting, thanks.
Permalink Submitted by graham on Tue, 01/12/2016 - 07:08.
This is interesting, thanks. We evaluated apdqc a few months back when we were experiencing table locks on a site that had to handle many writes to the node table simultaneously. In the end we held off using it until there is a stable release
The ultimate fix is to correct the code causing the notices, as you say (thanks for the link to SQL), not least because the notices could also indicate logic errors in certain conditions, but using this module to reduce the burden of watchdog writes is certainly an interesting idea, especially on sites where the code base is very dirty with huge numbers of notices to fix. In that scenario this module could ease the burden while the code is being improved.