No two Drupal websites are the same. They have different content, different user types, different traffic levels, different data structures and many other differences. That is why each site requires its own performance strategy. Unless you are running simple sites then it is not OK to simply switch on Drupal page caching and then forget about it. Here we examine a variety of performance related topics that ought to be considered when defining your own Drupal performance strategy.
Our Drupal 7 installation has served us well using a single, optimised MySQL database server. However, a desire to deliver advanced reporting and dashboards driven by Power BI required us to implement a replicated slave so that Power BI could draw data from a datasource that would not impact the performance of the database serving the website.
Mostly the configuration was straightforward:
Recently we received a call for help. The client had produced a new website that was great to look at, packed with fresh content and ready to launch. There was just one problem, performance.
Some pages, in particular those driven by Views that were returning a large amount of data, were taking way too long to load. Interestingly the client had found that enabling page caching was not helping, yet enabling Views caching did help, a lot.
Most sites will benefit from some form of caching, but for complex sites it is important to make sure the cache backend issuitable for the data you intend to cache.
For example, many others have already discussed the suitability of memory based caching for session data. The problem being that if memory becomes tight session data can be dropped meaning a user can be abruptly logged out of a website unexpectedly.
Drupal is able to automatically discover the files that it needs to read. It does this by scanning known directories such as module and theme directories for files that have known suffixes such as .module, .info and others.
As you can imagine, the larger your code base, the more resource this process consumes. Thankfully Drupal is intelligent enough to perform this scan only when required, not on every request. At least that is how the system is supposed to work.
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.