The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.I've got a site with user profiles provided by profile2. Whenever I save a user profile, it takes a really long time (~20 seconds). I've traced this through to apachesolr_attachments_entity_update() being called. This calls apachesolr_attachments_clean_index_table(), which then runs a delete query against apachesolr_index_entities_file for every single entity type in the system, which is what's actually taking the time.
I've managed to improve the performance by adding an index on parent_entity_type in my DB, but it seems really odd to me that it needs to run all these queries when saving an unrelated entity anyway. (Hence I'd add a patch for the index, but my gut feeling is more needs to be done here that that).
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | interdiff.txt | 811 bytes | claudiu.cristea |
| #7 | module_slows_down-2017705-7.patch | 1.41 KB | claudiu.cristea |
Comments
Comment #1
OliverColeman commented"Me, too". Our apachesolr_index_entities_file table has 182488 records, it takes about 6 seconds to run each delete query, and we have a lot of entity types, so creating/updating and deleting nodes takes a long time. Performing these table cleaning operations does seem unnecessary upon CRUD operations on entities. Can they be moved to a cron job?
I've marked this bug as Active with Priority Major as it makes the module unusable, at least for large numbers of attachments. Apologies if this is poor form, feel free to revert it back to normal priority if so.
Comment #2
Reuben Unruh commentedThere's a patch to move the table clean to a cron job in this issue.
Comment #3
mdupontGiven apachesolr_attachments_clean_index_table() doesn't do any operation that is specific to a given entity, it doesn't make sense to run it every time an entity is created, updated or deleted. This type of maintenance operation should rather be done at cron time.
Attached a patch that moves calls to apachesolr_attachments_clean_index_table() to a hook_cron(), and performs only 1 delete query instead of multiple ones. As an additional benefit, only 1 instance of the query will be run, eliminating the risk of deadlocks.
Comment #4
mdupontComment #5
mdupontComment #6
milesw commentedThe slowness is due to apachesolr_index_entities_file missing the appropriate indexes.
Whether or not apachesolr_attachments_clean_index_table() can be moved to cron is unclear, but the maintainers are already discussing that in the other issue.
Here is a patch to add the indexes and resolve the performance issue.
Comment #7
claudiu.cristea@milesw, thank you for the patch. I was looking for it. Anyway, because some sysadmins have already added indexes manually to quick save their servers it's good to add a check.
Comment #8
claudiu.cristeaComment #9
nironan commentedPatch does the job!
Comment #10
andras_szilagyi commented#8 works as intended
Comment #13
janusman commentedNoting I tried adding some of these but then started getting some warnings upon creating some new nodes with attached files. Not sure exactly what it was, so for now I reverted the changes. Still needs some work/testing IMO.
Comment #14
janusman commented