Skip to content

Latest commit

 

History

History
157 lines (111 loc) · 5.71 KB

optimizations.md

File metadata and controls

157 lines (111 loc) · 5.71 KB

Drupal and Mukurtu Optimizations

Packages for install have already been integrated into Mukurtu install documentation.

View execution time and memory usage for each page load:
Admin Menu > Configuration > Development > Devel settings

Check "Display page timer" and "Display memory usage"

Click "Save configuration"

Page Caching and CSS/JS Aggregation

Admin Menu > Configuration > Development > Performance

Caching

Check the box to "Cache pages for anonymous users"

Set "Minimum cache lifetime" to 1 hour

Set "Expiration of cached pages" to 1 day

Bandwidth Optimization

Check all the boxes here

These changes provide a noticeable performance improvement for guest viewing!

dblog Module

This module was previously known as "watchdog" and its database table is still named that. It is enabled by default to capture all website logging.

Empty Bloated DB Table

Our production Mukurtu site was generating so many deprecation warnings etc that it filled our /var/lib/mysql partition for MariaDB and prevented the database from starting. Greg was able to recover enough disk space from the partition by removing some old backup files to get MariaDB to start. Running drush cc all afterwards was able to recover more disk space to buy time for attempts at remediation. Attempting to empty the table by drush watchdog:delete all were unsuccessful and started causing a MariaDB file /var/lib/mysql/ibdata1 to start growing quickly. Research indicated it's not possible to regain storage used by this file without deleting and reimporting all database tables, so this process was cancelled before it completely filled the partition again. Reading the code found that internally this uses the TRUNCATE command which is supposed to be the most efficient way to empty a database table and reset its autoincrement value. But with this approach seeming like a recipe for disastar that would re-fill the table, other options were researched. It was found that re-creating the table anew with a different name, renaming the original, and then renaming the new table with the original's name would work. This approach worked, and deleting the large table after the new one was in place recovered the disk storage.

Retrieve the SQL to re-create the watchdog table. Copy the output and enter with a different table name, watchdognew. Rename the tables. Then drop the old table.

SHOW CREATE TABLE watchdog;

CREATE TABLE watchdognew ...

RENAME TABLE watchdog TO watchdogold, watchdognew TO watchdog;

DROP TABLE watchdogold;

Now the dblog module and the "watchdog" table can be used again. The cron maintenance task will clear the table down to an amount configured on the admin page "Configuration > Development > Logging and errors", i.e. /admin/config/development/logging again as well. This had failed while the table was enormous.

Disable dblog Module

To save the extra storage wear and CPU cycles, the dblog module can be disabled until needed to actually debug errors etc.

Go to the admin page "Modules", i.e. /admin/modules, search for "log", toggle off the "dblog" module, and click Save in the lower left.

PHP

APC Settings

Drupal documentation

Installed these additional packages just in case they help:

sudo yum install install php72-php-pecl-apcu-bc php72-php-pecl-apcu-devel

vim /etc/opt/remi/php72/php.d/90-mukurtu.ini:

apc.shm_size = 128M
apc.ttl = 3600

Didn't seem to have a noticeable effect on performance, but will leave for now.

realpatch_cache

Drupal documentation

Tested output of size in phpinfo page and never saw value over 300K. PHP 7.2's default value is 4M, which seems adequate.

Increase TTL value to 3600, one hour

vim /etc/opt/remi/php72/php.d/90-mukurtu.ini:

realpath_cache_ttl = 3600

Didn't seem to have a noticeable effect on performance, but will leave for now.

Zend OPcache

sudo yum install php72-php-opcache

Default settings match the recommended values except for opcache.revalidate_freq

vim /etc/opt/remi/php72/php.d/90-mukurtu.ini:

opcache.revalidate_freq = 60

This package provided noticeable performance improvement!

Further Research

Some reading indicates that PHP deployment via php-fpm rather than mod_fcgid may be more performant, at least partially because it is supposed to allow all PHP processes to share internal caching

Here are some links to potential further research into optimization:

  • db_maintenance module
    • Previous experience with the OPTIMIZE command for MariaDB informs to be skeptical this process will lead to noticeable improvements in performance
  • Memcache module
    • This or Varnish could probably improve performance but complicate the deployment of the site in general
  • Authcache module
    • Appears tricky customization would be required to see performance benefits
  • MariaDB Optimizations
    • Some of these may be fruitful in tweaking MariaDB config
  • Caching Resources
    • This has been reviewed to pick out specifics which looked like low-hanging fruit, but there are more resources on caching and optimization