As suggested by mig5, reverting 4f16634 and 7ac2c does fix the slowlyness. reverting 4f1 only does not help.

CommentFileSizeAuthor
#1 1067688.patch2.88 KBunivate
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

univate’s picture

Status: Active » Needs review
FileSize
2.88 KB

As 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.

univate’s picture

An 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.

anarcat’s picture

Status: Needs review » Needs work
Issue tags: +Performance

The 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...

univate’s picture

I 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?

anarcat’s picture

Title: Dashboard pretty slow on rc1 ( related to VBO) » bulk operation forms are too slow with thousands of packages
Priority: Minor » Major

Well, 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.)

anarcat’s picture

Version: 6.x-0.4-alpha3 » 6.x-2.0-alpha2
Status: Needs work » Fixed

i assume this is fixed by the new VBO code.

Status: Fixed » Closed (fixed)
Issue tags: -Performance

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

  • Commit 846def3 on 6.x-2.x, 7.x-3.x, dev-ssl-ip-allocation-refactor, dev-sni, dev-helmo-3.x by anarcat:
    Revert "make last commit function names and conditionnals more readable...

  • Commit 846def3 on 6.x-2.x, 7.x-3.x, dev-ssl-ip-allocation-refactor, dev-sni, dev-helmo-3.x by anarcat:
    Revert "make last commit function names and conditionnals more readable...