Closed (duplicate)
Project:
Insert
Version:
6.x-1.0
Component:
Code
Priority:
Normal
Category:
Support request
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
14 Mar 2011 at 04:39 UTC
Updated:
21 Mar 2011 at 15:05 UTC
hello
i have a somewhat larger base of Nody Types (11), Fields (11 custom) and ImageCache presets (~120).
everything is fine... until i enable this module, and configure fields to use it (or not).
what was once a 512KB 'dpl_content_node_field_instance' table, turns into 1.5MB once i setup the display order for JUST the cck Basic order of JUST a content type.
a row SQL export with ~1500 characters turns into a 9900 characters row export!
i discovered that the more i edit, the bigger it equally gets.
upon editing the last of the 11 content types, on the two last cck display order, the system would no longer respond - each request to edit the ordering would fail with lack of memory, each request to process ANY page would take an incredible amount of time.
just for the record, i was registering 460MB memory usage on apache, plus 60MB for APC, and the CPU was always under heavy load, starting at 60% and then jumping to 100%, something i never saw on this VPS from Linode. as for the table, it was huge! 12+MB. so basically, you can't dream about this module scaling, at all.
and the SQL file export? well, 6MB! just for that table.
take a look at a small sample of that sql in the txt attachment.
then i had the brilliant idea of uninstalling the module, but tada, it DOES NOT erase its remains in the DB, so the table remained the same and i had to redo the fields.
long story short, your module caused my a huge headache and 1 full night of work lost between diagnosing, work, gray hairs, etc) and a boss upset with me.
now to be more constructive... is there any way this module can be recoded to not behave this way, please?
the way it is, it is even __hardly__ of any use for small setups, because it's just too much overload.
and please add a routine to get rid of the remains from the 'dpl_content_node_field_instance' table.
| Comment | File | Size | Author |
|---|---|---|---|
| insert.txt | 41.38 KB | lpalgarvio |
Comments
Comment #1
lpalgarvio commentedcorrected version.
changing to critical because it really is critical.
Comment #2
quicksketchI don't think there's any possible way that Insert could be responsible for the problems you're seeing. Insert is used on tens of thousands of sites. If it caused such drastic side effects I'm such such issues would have been reported before this. The hooks that Insert uses are simply provided by CCK, Insert should make a total impact on your MySQL database less than 4K per content type, I have no idea how it could cause such issues. I suppose with your 120 ImageCache presets, it needs to save a setting for each ImageCache preset that you have set up, so that might push it around 100K.
In any case, this module should have little to no effect on performance. I think you're probably barking up the wrong tree.
Comment #3
lpalgarvio commentedi've though on the past it could be due to Content Display Order module, but then i tested again with it disabled, and it still happened, until i disabled Insert as well.
a messed up drupal installation could also be the issue, but i'm thinking atm that it's a bug.
will test further on a clean installation.
Comment #4
quicksketchI'm getting the same result over in the FileField queue for users that don't have Insert installed at all. Still not sure what the cause is. Let's consolidate over there, since I really don't think Insert could be responsible for this problem. #1095878: Widget array contains 260k+ items causing severe performance issues