Closed (fixed)
Project:
IP-based Determination of a Visitor's Country
Version:
8.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
3 Feb 2014 at 17:18 UTC
Updated:
6 Nov 2017 at 14:04 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
guile2912 commentedComment #4
guile2912 commentedComment #5
guile2912 commented1: lightspeed-updates-2187895-1.patch queued for re-testing.
Comment #6
guile2912 commentedSmall mistake I made patching 1.4 and making a diff out of 1.x !
Comment #7
tr commented@guile2912: Can you please take a look at #1592198: Optimization of updating geoip information? I tried the same thing years ago and provided a patch which I don't think anyone ever tested. But the bottom line is I saw no speed improvement at all. The patch is essentially the same as yours, except I do an unnecessary array_chunk() in the loop which might be slowing it down.
Comment #8
guile2912 commentedHello TR,
My patch stacks 200 (configurable) $query->values before calling a single $query->execute();, making it a reall bulk insertion.
For what I understood reading your patch (I might be wrong, I have not tested it for real), you were still doing a $query->execute(); for every line, so not changing much from the current one-insert-at-a-time technic.
The patch from Georgique was doing it aaaallllll at once, wich would make the server go out of memory on big data sets.
I am sure that as this patch let the user select the amount of queries he wants to stack, you can twick giving your sever memory.
And anyway, with as low as 200 queries stacked, the speed improvement is already incredible.
Comment #9
rcodinaYour patch works like a charm. I move this to critical because without your patch I can't get more than 29000 rows on "ip2country_temp" database table. With your patch I got 107170 which is amazing. Many thanks!
But I still have the same error after that amount rows get imported (not related to this issue):
Comment #10
rcodinaCombining this patch (#6) with the patch on related issue (drush integration) I managed to get all 165244 rows without any error. So I think this both patches should be commit ASAP. Importing IP data via drush is smarter than doing it via GUI.
Comment #11
rcodinaThe import also goes well on first module install (using this patch of course!).
Comment #12
guile2912 commentedThanks for head up rcodina.
I do not really understand with this is still not commited. Neither do I understand why I did not see your comments in 3 months ^^
So if I understand right, the import goes well on module installation, but on update you need to use the drush commmands otherwise it still times out ?
Comment #13
rcodina@rcodina It has been 3 months since I used this and I don't remember. But I guess I used drush for sure. But don't remember anything else. I'm sorry. But I think UI should still be an option. It's just a matter of committing two patches.
Comment #14
Morten Najbjerg commentedI had problems updating the database because of timeouts when getting the ARIA database.
This patch was magic. It pulled the database in in under 10 seconds.
Thank You.
Comment #15
guile2912 commentedGood to know this still helps and works :)
Thanks for your feedbacks Morten, I still have some hope this will be commited someday, or integrated in D8.
Comment #16
tr commentedRe-rolled patch against current HEAD, added some comments, and made minor coding standards changes.
Comment #18
tr commented@guile2912: Thank you so much for providing this patch, and thanks for your patience over the last few years when I didn't have a lot of time to work on Drupal.
My tests show the database now loads in about 1/6 the time. On my test server, this means it now takes ~15 seconds instead of ~90 seconds.
Committed. I will now port this same patch to D8.
Comment #19
tr commentedHere's the D8 patch for the testbot to look at.
Comment #21
tr commentedDoh.
This patch also needs to include a hook_update_N() to update the config from previous versions (I've written that, it's just not in the patch), but I'm going to hold off on that for a few days until I can get the migration template fixed and get rid of the obsolete hook_update_8000() that's in there now.
Comment #22
tr commentedPatch with the update hook.
Comment #24
tr commentedThat should fix it for Drupal 8 as well.
Thanks to all who helped out in this issue.
Comment #26
guile2912 commentedWohooo this is great :D, better late than never ^^, thanks for your time maintaining this.