|
|
|
| Столкнулся с проблемой: при экспорте БД проходит довольно много времени, в результате чего скрипт обрубался по таймауту. Решил это вставив в скрипт set_time_limit(0). На какое-то время этого хватило. Теперь другая проблема: запрашивающий сервер не дожидается ответа и скрипт снова останавливается на половине дороги.
Как это можно обойти? может ли скрипт выполняться сам по себе независимо ни от чего?
Вот что отвечает сервер
Произошла следующая ошибка:
Ответ нулевой длины
Кэш не получил никаких данных в ответ на этот запрос.
|
| |
|
|
|
|
|
|
|
для: Loki
(17.10.2005 в 16:26)
| | Скрипт тащит ответ по сети или с локальной машины? | |
|
|
|
|
|
|
|
для: cheops
(17.10.2005 в 20:01)
| | Скрипт выполняется на сервере и там же пишет данные. В броузер выводится только надпись об окончании архивации. | |
|
|
|
|
|
|
|
для: Loki
(17.10.2005 в 21:36)
| | А это потому что база данных думает долго преред выдачей ответа? Или скрипт уже начинает получать данные? | |
|
|
|
|
|
|
|
для: cheops
(17.10.2005 в 23:23)
| | Я так понимаю что не БД, а сам скрипт долго выполняется: он выбирает данные из БД, пишет их в переменную, архивирует и пишет в файл. | |
|
|
|
|
|
|
|
для: Loki
(18.10.2005 в 09:16)
| | Хм... а PHP работает как CGI-приложение или как модуль? Если как CGI-приложение, то скрипт должен отрабатывать до конца... | |
|
|
|
|
|
|
|
для: cheops
(18.10.2005 в 14:59)
| | Есть подозрение что как модуль, так как авторизация методом .htaccess у меня работает (вроде как при cgi подключении не должна?).
Получается, что надо оптимизировать код... плохо:( | |
|
|
|
|
|
|
|
для: Loki
(18.10.2005 в 16:19)
| | Да, тогда точно модулем... А почему плохо, наооброт интересно :))) (если, конечно, время не поджимает) | |
|
|
|
|
|
|
|
для: cheops
(18.10.2005 в 18:08)
| | Ну плоха не сама оптимизация, а то что дамп придется дробить на много файлов - не люблю такую помойку.
Кстати, мысль по поводу оптимизации: в цикле проверять сколько прошло времени с момента начала работы скрипта и, если время поджимает, то сохраняемся и выходим... точнее, еще лучше - перезагружаем скрипт автоматически... вот это уже интересно... В этом случае, скрипт будет исполнятся в зависимости от объемов данных.
теперь надо будет скрипт делать который все в кучу собирает:) | |
|
|
|
|
|
|
|
для: Loki
(19.10.2005 в 00:19)
| | Перезагружать автоматически не получится иначе все ограничения в 30 сек были бы бесполезны и их можно было бы обойти, загрузив сервер бесполезной работой по самые уши. Обычно каскад делают - скрипт работает - потом выводит пользователю сообщение: сделано столько-то процентов работы - продолжить? Пользователь жмёт "Да" и запускает новый скрипт. | |
|
|
|
|
|
|
|
для: cheops
(19.10.2005 в 15:01)
| | вы хотите сказать что если я сделаю рефреш через мета тег то это не сработает?
мне кажется мы друг друга неправильно поняли: по достижении определенного времени исполнения скрипт будет сохранять уже обработанные данные. Записывать данные о последней обработанной записи (он это и сейчас делает) и выводит в броузер страницу с рефрешем на самого себя. При запуске он проверяет какая запись была обработана последней и начинает работу со следующей... мне кажется - должно сработать. | |
|
|
|
|
|
|
|
для: Loki
(19.10.2005 в 23:10)
| | Через мета тэг сработает... только время для скрипта и для пользователя течёт по разному :))) Хотя здесь это не очень важно... да можно попробовать так - я такую же схему испльзовал когда запихивал содержимое 10 Мб XML-файла в базу, когда он у меня в памяти скрипта не убирался. Правда у меня не было ограничения по времени и нужно было просто в цикле загрузить файл по частям. | |
|
|
|
|
|
|
|
для: cheops
(20.10.2005 в 01:41)
| | А мнение пользователя я учитывать не собираюсь: отработал скрипт, предположим 27 сек - сохраняй данные и перезагружайся:) | |
|
|
|