The most of servers has max_execution_time parameter set to 30 seconds. It means - most of the admins cannot execute scripts which do too many queries at one time. There are also upload_max_filesize and memory_limit parameters...
Will it be taken into consideration in:
- Backup Database
- Restore Database
- Search Indexing
- 2.0.x -> 2.2 update script
For example - my database backup file is something about 130 MB. I cannot restore db using Restore Database option in 2.0.x...
max_execution_time
Forum rules
Discussion of general topics related to the new release and its place in the world. Don't discuss new features, report bugs, ask for support, et cetera. Don't use this to spam for other boards or attack those boards!
Discussion of general topics related to the new release and its place in the world. Don't discuss new features, report bugs, ask for support, et cetera. Don't use this to spam for other boards or attack those boards!
Re: max_execution_time
Emoticons doesn't work properly
It is not a bug report - I only want to say that i wanted to write "Question" emoticon - not "Confused".
It is not a bug report - I only want to say that i wanted to write "Question" emoticon - not "Confused".
- A_Jelly_Doughnut
- Registered User
- Posts: 1780
- Joined: Wed Jun 04, 2003 4:23 pm
Re: max_execution_time
Most of those were taken into consideraton for phpBB 2.0. You'll notice @set_time_limit() calls all over the place. As for the memory, the upload limit cannot be worked around, but using unset() and mysql_free_result() appropriately will keep memory usage of the scripts down. And again, these are in 2.0; I see no reason why that should change in 2.2.
A_Jelly_Doughnut
- cyberCrank
- Registered User
- Posts: 560
- Joined: Wed Jan 28, 2004 3:38 am
- Location: Ethereal Bliss
Re: max_execution_time
These type things are definitely needed to help with the growing number of server-side limitations...
To get around some of the client-server limitations (query limits, backup and restore webpage-based timeouts, server script timeouts, etc.), many of us have resorted to manual backup and restore procedures using other database-related PHP and system level jobs (e.g., cron jobs) to do things like backups. phpBB 2.0 has had problems related to backups and restores of large databases for some time. Running jobs that spawn system-level mysqldump commands allow efficient server-side backups (plus fast and small) and also use server-side gzip to help further reduce size to facilitate backup and restore operations.
Although having a reliable process within phpBB would be very helpful for general users, having and using Cron jobs and PHP scripts also help to automate this process, email notification of success, and FTP scripts to get the backups downloaded for client-side storage and archiving (and to do a similar upload and efficient server-side retore as and when needed).
There are times that maybe splicing are needed, but using this method has overcome many past problems with large-database backups, mostly becouse the objective is to make backups, etc. efficient, and all related files to be small.
To get around some of the client-server limitations (query limits, backup and restore webpage-based timeouts, server script timeouts, etc.), many of us have resorted to manual backup and restore procedures using other database-related PHP and system level jobs (e.g., cron jobs) to do things like backups. phpBB 2.0 has had problems related to backups and restores of large databases for some time. Running jobs that spawn system-level mysqldump commands allow efficient server-side backups (plus fast and small) and also use server-side gzip to help further reduce size to facilitate backup and restore operations.
Although having a reliable process within phpBB would be very helpful for general users, having and using Cron jobs and PHP scripts also help to automate this process, email notification of success, and FTP scripts to get the backups downloaded for client-side storage and archiving (and to do a similar upload and efficient server-side retore as and when needed).
There are times that maybe splicing are needed, but using this method has overcome many past problems with large-database backups, mostly becouse the objective is to make backups, etc. efficient, and all related files to be small.
Re: max_execution_time
The limitations of the backing up/restoring of database are more to do with limitations of the HTTP protocol implementation more than anything. There's a limit to how much mileage you can get with web forms and HTTP 1.0/1.1 with bigger files.
Re: max_execution_time
Very true.R45 wrote:The limitations of the backing up/restoring of database are more to do with limitations of the HTTP protocol implementation more than anything. There's a limit to how much mileage you can get with web forms and HTTP 1.0/1.1 with bigger files.
As was said above, the best way is to use a cronjob or get shell access and use the mysqld utility to backup your database.
Re: max_execution_time
The code in the current CVS is actually quite good at freeing memory when it is not required anymore and mimimising memory usage where possible.
Filesize limits there is not much phpBB can actually do about them and with 130b databases other methods are actually more reliable than trying to do it over HTTP anyway.
With regards to timelimits, there are only a very few scripts that this affects, I think (although I don't have the code in front of me) that the Mass Mailer has been altered to take this into account, and I would assume that any upgrade script will follow a step-by-step process if necessary to remain within the limits (although don't quote me on that as I don't know the plans for that script yet)
Filesize limits there is not much phpBB can actually do about them and with 130b databases other methods are actually more reliable than trying to do it over HTTP anyway.
With regards to timelimits, there are only a very few scripts that this affects, I think (although I don't have the code in front of me) that the Mass Mailer has been altered to take this into account, and I would assume that any upgrade script will follow a step-by-step process if necessary to remain within the limits (although don't quote me on that as I don't know the plans for that script yet)
-
- Registered User
- Posts: 11
- Joined: Tue Jul 20, 2004 6:15 pm
Re: max_execution_time
An associated topic, I got a memory execution problem for the admin page.
Re: max_execution_time
And this supprises you being that it is development code and all. NO BUG REPORTS.richardwhiuk wrote:An associated topic, I got a memory execution problem for the admin page.
-
- Registered User
- Posts: 11
- Joined: Tue Jul 20, 2004 6:15 pm
Re: max_execution_time
I make a simmilar comment and I get complained as a bug report? What the hell?
In development bug reports are often USEFUL to the developers.
In development bug reports are often USEFUL to the developers.