Contrib.social

Performance optimisation

Open on Drupal.org →
Created on 23 June 2025, 21 days ago

This is a wonderful idea and it will prove very useful.

I have some performance concerns with the initial implementation, though I am not nearly knowledgeable enough about the underlying back end code and processes to get into the nitty gritty of how the code should look. Instead I follow the mantra that lightweight-as-possible is the way to go.

Problem/Motivation

Heavy activity in the admin area under stress and lots of editing can contribute to performance issues and even outages. We don't usually have the protection of things like caching services and CDNs in the admin section. And by the very nature of this feature we're on production where performance matters most.

Proposed resolution

File this proposed resolution in 'more questions than answers'.

One way we might do a lightweight check and get out of there fast:

Editors generally work in content areas. We want to check for things where editors usually don't go. So, we should do what we can to optimise checks and not do checks where they usually do go, like /admin/content .

/admin/config
/admin/structure/types
/admin/structure/views
are examples of places where I should see the warning and don't need checks.

/admin/modules might set off an alarm.

/admin/content is probably all content. Return.
node add and node edit etc. Don't use resources. Return.

/admin/structure/taxonomy is a nice place for real checks because it contains both config and content.
/admin/people contains both.
(unless we get very granular)

Some unexpected paths provided by less used contributed modules? Do checks.

Seems to me straightforward enough maintain an array of wildcard content paths and config paths.

Would paths checks help or hinder with performance? I dunno but I suspect help.

For discussion

By this or some other means, optimise logic. Perhaps modules should provide their own granular checks and this becomes is an API instead.

✨ Feature request
Status

Active

Version

1.0

Component

Code

Created by

🇬🇧United Kingdom tonypaulbarker Leeds

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

Comments & Activities

  • Issue created by @tonypaulbarker
  • Comment 21 days ago →
    🇬🇧United Kingdom tonypaulbarker Leeds
  • Comment 21 days ago →
    🇬🇧United Kingdom rachel_norfolk UK

    Okay, you have me intrigued as to what the performance concerns might be.

    There’s currently a hook_form_alter that checks to see whether the form class has a particular method. See:

    $form_object = $form_state->getFormObject();
if (method_exists($form_object, 'getEditableConfigNames')) {
  //Add a message.
}

    Plus checking for a couple of other specific form classes that we know would alter config but work slightly differently.

    Do you think inspecting the class would be intensive?

  • Comment 21 days ago →
    🇬🇧United Kingdom tonypaulbarker Leeds

    @rachel_norfolk I don't think so. My concern is about the frequency of these transactions so optimising and marginal gains seem worthwhile where they can be made. There are already good measures in place. Actions (if any) will come out in testing and review.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024