Comments 11
Demo. Google Chrome. Версия 22.0.1229.79 m
Request URL:http://bfmn.ru/scriptoffset/scriptoffset.php
Request Method:POST
Status Code:200 OK
Пустой ответ и нет реакции.
Request URL:http://bfmn.ru/scriptoffset/scriptoffset.php
Request Method:POST
Status Code:200 OK
Пустой ответ и нет реакции.
«Хотелось бы разбить обработку файла на несколько частей и запускать скрипт в работу уже по частям.» — зачем? Только для прогрессбара и возможности остановить? Вам в ответах написали пару неплохих решений которые выполнят те же задачи, но при этом будут значительно быстрее, легче по ресурсам и пр. Или речь о хостинге который не позволяет ставить время выполнения и убивать процесс (хотя последнее можно и обойти)?
Не смотрел кода, но если я правильно понял по описанию, каждый запрос это новый новый запуск скрипта, обработанные строки пропускаются, т.е. скрипт должен пропустить в файле миллион строк чтобы сотню обработать?
Не смотрел кода, но если я правильно понял по описанию, каждый запрос это новый новый запуск скрипта, обработанные строки пропускаются, т.е. скрипт должен пропустить в файле миллион строк чтобы сотню обработать?
Предлагаю вам пойти дальше:
Во-первых, отказаться от cookies, и хранить информацию о прогрессе скрипта на сервере. Все равно ведь ваш скрипт, я так понял, предназначен для админской части. А раз так, то многопрофильность ему не нужна, достаточно будет одного экземпляра. Правда в этом случае придется отслеживать конкурентов.
Во-вторых, отказаться от итераций. Вместо этого — один сплошной поток операций. В вашем случае это будет цикл по всем строкам CSV. Внутри цикла периодически записывать текущее состояние, в базу или файл — не принципиально. Если скрипт оборвется по таймауту, то в следующий раз цикл начинать с последней запомненной строки. Это конечно может привести к лишним запросам к базе, если интервал м/у записями состояния будет большим, но это не страшно.
Во-третьих, если хотите видеть актуальный прогресс выполнения, то нужно создать еще один скрипт, который читает текущий прогресс из базы (файла) и выдает браузеру. На клиенте, одновременно с запуском основного скрипта, запускаете серию период-ких запросов на чтение прогресса до тех пор, пока не закончится/оборвется основной скрипт.
Во-первых, отказаться от cookies, и хранить информацию о прогрессе скрипта на сервере. Все равно ведь ваш скрипт, я так понял, предназначен для админской части. А раз так, то многопрофильность ему не нужна, достаточно будет одного экземпляра. Правда в этом случае придется отслеживать конкурентов.
Во-вторых, отказаться от итераций. Вместо этого — один сплошной поток операций. В вашем случае это будет цикл по всем строкам CSV. Внутри цикла периодически записывать текущее состояние, в базу или файл — не принципиально. Если скрипт оборвется по таймауту, то в следующий раз цикл начинать с последней запомненной строки. Это конечно может привести к лишним запросам к базе, если интервал м/у записями состояния будет большим, но это не страшно.
Во-третьих, если хотите видеть актуальный прогресс выполнения, то нужно создать еще один скрипт, который читает текущий прогресс из базы (файла) и выдает браузеру. На клиенте, одновременно с запуском основного скрипта, запускаете серию период-ких запросов на чтение прогресса до тех пор, пока не закончится/оборвется основной скрипт.
Целью было получить с одной стороны простое (его не нужно настраивать, не нужно лезть в конфиги сервера, не нужно создавать дополнительные таблицы в базе данных), с другой стороны универсальное решение, чтобы его можно было использовать на любом сайте с любой CMS, на любом сервере, даже на shared-хостинге, который не позволяет ставить время выполнения скрипта.
Я и не предлагал вам лезть в конфиги сервера. Всего лишь изменить алгоритм взаимодействия сервера и клиента.
Можно обойтись и без дополнительных таблиц в БД. Я не говорил что это обязательно. Что в конце концов стоит сериализовать переменную, хранящую число пройденных строк, в файл, а потом восстановить ее? Это же сущий пустяк.
И к времени выполнения скрипта я тоже не предлагал привязываться. Оборвется скрипт — ничего страшного. При следующем запуске десериализуем упомянутую переменную и продолжаем процесс с соотв-щей строки. Правда, чтобы не было издержек, придется делать сериализацию после каждой строки. Но это не должно сказаться на быстродействии.
Таким образом, такое более продвинутое (имхо) решение тоже можно использовать на любом… shared-хостинге. Собственно я его сам и использую, правда для немного других целей.
Можно обойтись и без дополнительных таблиц в БД. Я не говорил что это обязательно. Что в конце концов стоит сериализовать переменную, хранящую число пройденных строк, в файл, а потом восстановить ее? Это же сущий пустяк.
И к времени выполнения скрипта я тоже не предлагал привязываться. Оборвется скрипт — ничего страшного. При следующем запуске десериализуем упомянутую переменную и продолжаем процесс с соотв-щей строки. Правда, чтобы не было издержек, придется делать сериализацию после каждой строки. Но это не должно сказаться на быстродействии.
Таким образом, такое более продвинутое (имхо) решение тоже можно использовать на любом… shared-хостинге. Собственно я его сам и использую, правда для немного других целей.
1. Зачем два последних шага? Причём сначала сервер сообщает что обработал 50 записей и это ни что иное как 98% работы, а затем ещё раз 50 записей, но это уже 100%.
2. Отличаются форматы offset. Во всех ответах это integer, а в самом последнем это строка.
Код не читал, но пахнет он не очень хорошо.
3. В вашем скрипте ограничение на количество строк, которое он обрабатывает за 1 раз. Но это не очень удобно для больших объёмов информации. Если вы хотите сделать импорт быстрее, то должны выполнить минимум запросов к серверу, а в каждом запросе обработать максимум строк. Очень часто не известно каким является этот максимум. По этому, нужно делать ограничение по времени. Например, скрипт работает в течении 1 минуты и обрабатывает столько строк сколько успеет. Или пусть он работает max_execution_time / 2.
4. Какой смысл делать это на аяксе? Единственный плюс — это плавность ползунка когда у вас 50 запросов за 3 секунды. Но если делать каждый запрос по 5 минут, то можно перезагрузить страницу целиком. Зато у аякса есть огромный минус: он значительно усложняет отладку скрипта импорта. Бывает, клиент звонит через пол года после сдачи проекта и говорит что импорт отваливается на 958 строке и он не видит никаких ошибок и даже не может ничего скопипастить. По этому приходится просить у него import.xls и самому запускать скрипт с открытым фаербагом.
Я использую такой вывод (обычный лог — файл около 120мб...).
Можно им управлять и через AJAX (db нужна для команд).
for ($i=1;$i<$lines;$i++){
sleep(1);///что-то делаем…
echo 'Строка: '.$i.' успешно обработана…
';
ob_flush();flush();
////проверка базы: есть ли команда через ajax?
}
Можно им управлять и через AJAX (db нужна для команд).
for ($i=1;$i<$lines;$i++){
sleep(1);///что-то делаем…
echo 'Строка: '.$i.' успешно обработана…
';
ob_flush();flush();
////проверка базы: есть ли команда через ajax?
}
Илья, ваше решение оказалось очень кстати и легко расширяемо! Спасибо :)
Sign up to leave a comment.
Реализация пошаговой работы PHP-скрипта с помощью AJAX