|
[
Permalink
| « Hide
]
Dan Marsden added a comment - 25/Apr/08 07:55 AM
...at least I don't "think" the actual backup process uses that function, as I seem to get user files in my 1.9 backups.... need to investigate that further.... potentially a problem with the scheduled backup as they use different functions to execute the backup....
hmmm... the function backup_copy_user_files doesn't look great either - it does 1 db query for every user that has a user_directory (potentially every user on the site) for each backup. - not good!
does this: then for each $userlist does: $data = count_records("backup_ids","backup_code",$preferences->backup_unique_code, "table_name","user", "old_id",$userid) so if 3000 users with directories = 3000 queries .... if running cron based backups... that's a whole lot of db queries, when it might be able to get away with 1 query!
Dan Hi Dan,
some comments about your two points: 1) About user_files_check_backup(). I really think we could skip it safely, after all it's not used, as you say, by backup_copy_user_files () so we'll save a least 2*user queries. Or we can, alternatively, if want to continue giving feedback... do something like:
2) About the backup_copy_user_files () I think we should "revert" the process so, instead of doing the get_user_directories() call and then check for each user with the count_records() we should:
Good research! Ciao Total improvement with this 2 changes will be 3*number of users in backup queries saved. Cool! B-)
Hi Eloy,
we could do that with user_files_check_backup - but it doesn't count the number of "files" that will be saved - just the number of users with files that will be saved..... - so IMO we need to create a new lang that says "Users with files" and display that instead of "files" beside the number. have attached a patch that does this for user_files_check_backup (but we will need to add the lang somewhere...)
Dan here's my first go at the backup_copy_user_files function - I haven't tested these changes as much as I'd like yet - will do that tomorrow before I commit anything to HEAD
Dan Hi Dan,
I've take a look to your patches. They look good 1) You've used set_records_select_menu(), I would start using recordset functions from now - get_recordset_select() or get_recordset_sql() - to prevent BIG numbers of records to eat memory. See rs_fetch_next_record() php docs about how to use them and iterate properly. 2) You've deleted these lines in the user_files_check_backup() function: //Do some output I'd keep them there because they use to prevent browser timeouts by continuously flushing data to client. 3) I'd add the 2 lines above in backup_copy_user_files() too. It's missing them. The rest looks perfect. Thanks! Ciao thanks Eloy - good to know about the recordset stuff! - didn't think the backup_flush would be needed in files_check_backup() anymore as it should be quite fast....but considering the backup does take a bit of time it makes sense to add it back in (and add it to copy_user_files() as well.
OU are going to test the patch for me - I'll wait to hear back from them before I commit anything.
Dan attaching fullpatch file - seems to test ok in my install!
thanks,
Dan patch now in HEAD - would prefer some "peer-review" before I commit to 1.9Stable
Dan now in 1.9Stable as well.
Dan |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||