лампа: Как творить.Zip-архив больших файлов для пользователя на лету, без перебоев с диском/процессором

Вы можете использовать popen() ( документы) или proc_open() ( документы) для выполнения команды unix (например, zip или gzip) и возврата стандартного вывода в виде потока php. flush() ( docs) сделает все возможное, чтобы передать содержимое выходного буфера php в браузер.

Объединение всего этого даст вам то, что вы хотите (при условии, что ничто другое не помешает - см. esp. предостережения на странице документов для flush()).

( Примечание: не используйте flush(). Смотрите обновление ниже для подробностей.)

Что-то вроде следующего может сделать свое дело:

<?php
// make sure to send all headers first
// Content-Type is the most important one (probably)
//
header('Content-Type: application/x-gzip');

// use popen to execute a unix command pipeline
// and grab the stdout as a php stream
// (you can use proc_open instead if you need to 
// control the input of the pipeline too)
//
$fp = popen('tar cf - file1 file2 file3 | gzip -c', 'r');

// pick a bufsize that makes you happy (64k may be a bit too big).
$bufsize = 65535;
$buff = '';
while( !feof($fp) ) {
   $buff = fread($fp, $bufsize);
   echo $buff;
}
pclose($fp);

Вы спросили о "других технологиях": на что я отвечу: "все, что поддерживает неблокирующий ввод-вывод на протяжении всего жизненного цикла запроса". Вы могли бы создать такой компонент, как автономный сервер на Java или C/C++ (или на любом из многих других доступных языков), , если бы вы были готовы погрузиться в "грязные" проблемы неблокирующего доступа к файлам и тому подобного.

Если вы хотите неблокирующая реализация, но вы предпочли бы избежать "грязного и грязного", самым простым путем (IMHO) было бы использовать NodeJS. В существующем выпуске nodejs есть много поддержки для всех функций, которые вам нужны: используйте модуль http (конечно) для http-сервера; и используйте модуль child_process для создания конвейера tar/zip/любого другого.

Наконец, если (и только если) вы используете многопроцессорный (или многоядерный) сервер и хотите получить максимальную отдачу от nodejs, вы можете использовать Spark2 для запуска нескольких экземпляров на одном порту. Не запускайте более одного экземпляра nodejs на ядро процессора.

Обновление (из отличного отзыва Бенджи в разделе комментариев к этому ответу)

1. Документы для fread() указывают, что функция будет считывать только до 8192 байт данных одновременно из всего, что не является обычным файлом. Поэтому 8192 может быть хорошим выбором размера буфера.

[редакционное примечание] 8192 является почти наверняка значение, зависящее от платформы - на большинстве платформ fread() будет считывать данные до тех пор, пока внутренний буфер операционной системы не опустеет, после чего он вернется, позволяя ОС снова асинхронно заполнять буфер. 8192 - это размер буфера по умолчанию во многих популярных операционных системах.

Существуют и другие обстоятельства, которые могут привести к тому, что fread вернет даже меньше 8192 байт - например, "удаленный" клиент (или процесс) медленно заполняет буфер - в большинстве в некоторых случаях fread() вернет содержимое входного буфера как есть, не дожидаясь его заполнения. Это может означать, что возвращается где угодно от 0..байт os_buffer_size.

Мораль такова: значение, которое вы передаете fread() как buffsize, следует считать "максимальным" размером - никогда не предполагайте, что вы получили запрошенное количество байтов (или любое другое число, если на то пошло).

2. Согласно комментариям к документам fread, несколько предостережений: волшебные цитаты могут вмешиваться и должен быть отключен.

3. Настройка mb_http_output('pass') ( документы) может быть хорошей идеей. Хотя 'pass' уже является настройкой по умолчанию, вам может потребоваться указать ее явно, если ваш код или конфигурация ранее изменили ее на что-то другое.

4. Если вы создаете zip-файл (в отличие от gzip), вам следует использовать заголовок типа содержимого:

Content-type: application/zip

Или... вместо этого можно использовать "приложение/октетный поток". (это общий контент тип, используемый для двоичных загрузок всех видов):

Content-type: application/octet-stream

И если вы хотите, чтобы пользователю было предложено загрузить и сохранить файл на диск (вместо того, чтобы браузер мог попытаться отобразить файл в виде текста), вам понадобится заголовок content-disposition. (где имя файла указывает имя, которое должно быть предложено в диалоговом окне сохранения):

Content-disposition: attachment; filename="file.zip"

Также следует отправить заголовок длины содержимого, но с этим методом это сложно, так как вы не знаете, что такое почтовый индекс. точный размер заранее. Есть ли заголовок, который можно настроить так, чтобы он указывал, что содержимое "потоковое" или имеет неизвестную длину? Кто-нибудь знает?

Наконец, вот пересмотренный пример, в котором используются все предложения @Бенджи (и который создает ZIP-файл вместо файла TAR.GZIP):

<?php
// make sure to send all headers first
// Content-Type is the most important one (probably)
//
header('Content-Type: application/octet-stream');
header('Content-disposition: attachment; filename="file.zip"');

// use popen to execute a unix command pipeline
// and grab the stdout as a php stream
// (you can use proc_open instead if you need to 
// control the input of the pipeline too)
//
$fp = popen('zip -r - file1 file2 file3', 'r');

// pick a bufsize that makes you happy (8192 has been suggested).
$bufsize = 8192;
$buff = '';
while( !feof($fp) ) {
   $buff = fread($fp, $bufsize);
   echo $buff;
}
pclose($fp);

Обновление: (2012-11-23) Я обнаружил, что вызов flush() в цикле чтения/эха может вызвать проблемы при работе с очень большими файлами и/или очень медленные сети. По крайней мере, это верно при запуске PHP как cgi/fastcgi за Apache, и кажется вероятным, что та же проблема возникнет и при запуске в других конфигурациях. Проблема, по-видимому, возникает, когда PHP сбрасывает вывод в Apache быстрее, чем Apache может фактически отправить его через сокет. Для очень больших файлов (или медленных подключений) это в конечном итоге приводит к переполнению внутреннего выходного буфера Apache. Это приводит к тому, что Apache убивает процесс PHP, что, конечно же, приводит к зависанию загрузки или преждевременному завершению, при этом выполняется только частичная передача.

Решение состоит в том, чтобы вообще не вызывать flush(). Я обновил приведенные выше примеры кода, чтобы отразить это, и я поместил примечание в текст вверху ответа.