Я сейчас пытаюсь сделать то же самое;он в основном * завершен (* см. раздел «Проблемы» ниже).
Основная концепция, которую я использую, состоит в том, чтобы иметь 2 файла / процесса:
- Планировщик (запускает задачу и может вызываться дляполучать обновления)
- Задача (фактически выполняет задачу архивирования)
Планировщик будет:
- Создать уникальное обновлениетокен и сохранение в кэш (APC)
- Вызовите страницу задач с помощью асинхронного curl_multi_exec, передавая update_token
- Возврат токена в формате JSON ИЛИ
- Возврат содержимогоAPC под update_token (в моем случае это простой массив состояний) как JSON
Задача:
- Обновление APC со статусом, используя токен обновления
- Выполните реальную работу:)
На стороне клиента
Вам понадобится JavaScript для вызоваПланировщик, получите токен взамен, затем вызовите Планировщик, передав update_token, чтобы получить обновления, и затем используйте этиизмененные значения для обновления HTML.
** Потенциальные ловушки **
Сессии могут быть проблемой.Если у вас тот же сеанс, вы заметите, что ваш браузер (или это Apache?) Ждет завершения первого запроса в сеансе, прежде чем возвращать другие.Вот почему я храню в APC.
Текущие проблемы
Проблема с классом ZipArchive состоит в том, что он кажется всей рабочей работе в -> close (), в то время как метод addFile, по-видимому, занимает совсем немного времени.
В качестве обходного пути вы можете закрыть, а затем снова открыть архив с определенными интервалами в байтах или файлах.Это на самом деле немного замедляет процесс сжатия, но в моем случае это приемлемо, так как визуальный индикатор выполнения лучше, чем просто ожидание без указания того, что происходит.