Add index on hostname column

Created on 28 April 2021, over 3 years ago
Updated 8 October 2023, 12 months ago

Problem/Motivation

When the honeypot_user table is large (in our case over 61k entries) some operations are slow because there's no index on the "hostname" database column.

Steps to reproduce

In our case, the slave replication showed "The slave is applying a ROW event on behalf of a DELETE statement on table honeypot_user and is currently taking a considerable amount of time (61 seconds)." Also in the .module file there's a query condition against "hostname" which is an unindexed query.

Proposed resolution

Add an index to hostname field.

✨ Feature request
Status

Fixed

Version

2.1

Component

Code

Created by

πŸ‡¨πŸ‡¦Canada minoroffense Ottawa, Canada

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • πŸ‡¨πŸ‡¦Canada sagesolutions

    Index also needs to be added when using READ-COMMITTED as the database transaction isolation level.

    Currently, there is an error on the status page due to this module.

    For this to work correctly, all tables must have a primary key. The following table(s) do not have a primary key: honeypot_user. See the setting MySQL transaction isolation level page for more information.

    Currently running on Drupal 10.1.1

  • πŸ‡ΊπŸ‡ΈUnited States tr Cascadia

    The following table(s) do not have a primary key: honeypot_user.

    That is a different issue, and that was fixed in -dev six weeks ago.

  • Status changed to Needs review about 1 year ago
  • Open in Jenkins β†’ Open on Drupal.org β†’
    Core: 9.5.5 + Environment: PHP 7.3 & MySQL 5.7
    last update about 1 year ago
    29 pass
  • πŸ‡§πŸ‡ͺBelgium mr.baileys πŸ‡§πŸ‡ͺ (Ghent)

    Adding an additional index on the hostname-column does make sense. I ran a test with 100k records in the {honeypot_user}-table: the query executed in \Drupal\honeypot\HoneypotService::getTimeLimit() becomes 35x faster (from 0.073 seconds to 0.002 seconds) for anonymous users.

    In our case, the slave replication showed "The slave is applying a ROW event on behalf of a DELETE statement on table honeypot_user and is currently taking a considerable amount of time (61 seconds)."

    The only condition used when deleting rows in Honeypot is "timestamp < _expire_limit_", so adding an index on the hostname column will not fix that issue (maintaining an additional index might even make it worse.)

  • Open in Jenkins β†’ Open on Drupal.org β†’
    Core: 9.5.5 + Environment: PHP 7.3 & MySQL 5.7
    last update 12 months ago
    29 pass
  • πŸ‡ΊπŸ‡ΈUnited States tr Cascadia

    Here's a re-roll that adds a test fixture and moves the test case into its own class. Like core, we really should be making one test class per update hook, rather than trying to lump all the update tests into one class and one fixture.

  • Open in Jenkins β†’ Open on Drupal.org β†’
    Core: 10.1.x + Environment: PHP 8.2 & MySQL 8
    last update 12 months ago
    29 pass
    • TR β†’ committed 5540bb2a on 2.1.x
      Issue #3211202 by mr.baileys, TR: Add index on hostname column
      
  • Status changed to Fixed 12 months ago
  • πŸ‡ΊπŸ‡ΈUnited States tr Cascadia

    Committed. Thanks.

  • Automatically closed - issue fixed for 2 weeks with no activity.

Production build 0.71.5 2024