Problem/Motivation
LibraryDependencyResolver::getMinimalRepresentativeSubset is used as part of the new asset pipeline which is used to generate urls and dependencies. This can be a pretty big deal for high performance websites as the consequence can be that the generated hash when generating the js / css file and when delivering said file wont match, causing increase load as the website now need to generate the file on every request.
Steps to reproduce
I will provide a patch with a test case, as that is the easiest way to reproduce the error.
Proposed resolution
Correct the code in getMinimalRepresentativeSubset
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | 3400485-test-fail.patch | 1.84 KB | googletorp |
Issue fork drupal-3400485
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
googletorp commentedI have created a test case which shows the failing issue and created a fix for the problem in the issue fork.
In general the problem is that before we did this:
The key problem is here:
I guess whoever wrote this assumes that this gives you the sum of the two arrays, but that is not the case, this only add the dependencies that exceeds the amount of dependencies we have of the left hand side. The test case illustrates this.
Comment #3
googletorp commentedComment #4
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue.
While you are making the above changes, we recommend that you convert this patch to a merge request. Merge requests are preferred over patches. Be sure to hide the old patch files as well. (Converting an issue to a merge request without other contributions to the issue will not receive credit.)
Comment #6
nod_Created a MR from your branch so that the issue can be reviewed
Comment #7
smustgrave commentedChange I believe makes sense to avoid duplicates
Comment #8
xjmSaving credits.
Comment #9
xjmFinally got the test-only job to run and confirmed the results still match the previous test-only patch:
Comment #13
xjmCommitted to 11.x, 10.2.x, and 10.1.x as a minimally disruptive data integrity bugfix. Thanks!
Comment #14
wim leersWow! Looks like this was a regression introduced by #2407187: Optimize LibraryDependencyResolver::getMinimalRepresentativeSubset() and win >=4%, since that changed the logic originally introduced by #2368797: Optimize ajaxPageState to keep Drupal 8 sites fast on high-latency networks, prevent CSS/JS aggregation from taking down sites and use HTTP GET for AJAX requests.
This likely reduced the ~4% performance improvement that #2407187 brought, but obviously correctness is more important.
Comment #16
bkosborneSo glad someone else was able to narrow down the problem here. I spent a long time on this in #3397713: [Performance regression] Starting with Drupal 10.1, some sites hit PHP for every page view due to aggregated asset URL hash mismatch from different order of asset items but wasn't able to pin it down. Thank you!!