Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
As suggested by mig5, reverting 4f16634 and 7ac2c does fix the slowlyness. reverting 4f1 only does not help.
Comment | File | Size | Author |
---|---|---|---|
#1 | 1067688.patch | 2.88 KB | univate |
Comments
Comment #1
univate CreditAttribution: univate commentedAs with most performance issues, the simplest solution could be to just caching the options in that list.
This patch isn't complete as it doesn't clear the cache anywhere which probably only needs to happen when hosting features get enabled/disabled.
Ofcourse you can also clear cache manually.
Comment #2
univate CreditAttribution: univate commentedAn alternative solution here could be to add another variable/flag into the task definition array to indicate whether it should be available as a bulk task - but I think adding options like that is somewhat messy.
Comment #3
anarcat CreditAttribution: anarcat commentedThe patch doesn't fix the performance issue for me. I have reverted 4f16634 and 7ac2c from the 0.4 branch for the time being.
We should work on having metadata in the tasks instead. Note that the master branch still has the code that inspects the forms...
Comment #4
univate CreditAttribution: univate commentedI wonder if a bigger issue is being overlooked here. Why should forms take so long to generate.
If a form needs to query a stuff from the database which takes multiple seconds to retrieve and use can we store/cache some of that information?
That would mean clone/migrate forms load faster as well as fix this issue?
Comment #5
anarcat CreditAttribution: anarcat commentedWell, there's a general issue with the migrate form there and the hosting package data structure. There are a few issues around that:
* #955854: Site form can be very slow with huge number of platforms and packages
* #1033072: migrate interface takes forever (litterally) to load
* #1034520: Cleanup zombie entries in hosting_package_* tables?
Those issues are probably all related to the "zombie" issue, but I'm hesitant of just cleaning up those tables, because they do show where bottlenecks are. For example, in the fixed issue above, adding an index on the hosting_package* tables fixed the problem. Here, we found another problem in the site form that doesn't scale well, and we should fix that too.
I think the workaround here is to simply set metadata (#interactive?) in the task that will remove it from the bulk operations. (In fact, maybe that could be a #bulk setting that would make the task show up in the form instead.)
Comment #6
anarcat CreditAttribution: anarcat commentedi assume this is fixed by the new VBO code.