LÁMPARA: Cómo crear.Zip de archivos grandes para el usuario sobre la marcha, sin problemas de disco/CPU

Puede utilizar popen() (docs) o proc_open() (docs) para ejecutar un comando de unix (por ejemplo. zip o gzip), y volver stdout como un flujo php. flush() (docs) hará todo lo posible para enviar el contenido del búfer de salida de php al navegador.

Combinar todo esto te dará lo que quieres (siempre que nada más se interponga en el camino see ver esp. las advertencias en la página docs para flush()).

(Nota: no utilice flush(). Ver la actualización a continuación para detalles.)

Algo como lo siguiente puede hacer el truco:

<?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);

Usted preguntó acerca de "otras tecnologías": a lo que voy a decir, "cualquier cosa que soporte e/s sin bloqueo para todo el ciclo de vida de la solicitud". Podría construir un componente como un servidor independiente en Java o C/C++ (o cualquiera de muchos otros lenguajes disponibles), si estuviera dispuesto a entrar en el "down and dirty" de acceso a archivos sin bloqueo y demás.

Si quieres un implementación sin bloqueo, pero preferirías evitar el "down and dirty", la ruta más fácil (IMHO) sería usar NodeJS. Hay mucho soporte para todas las características que necesita en la versión existente de nodejs: use el módulo http (por supuesto) para el servidor http; y use el módulo child_process para generar la canalización tar/zip/whatever.

Finalmente, si (y solo si) está ejecutando un servidor multiprocesador (o multinúcleo) y desea aprovechar al máximo nodejs, puede usar Spark2 para ejecutar varias instancias en el mismo puerto. No ejecute más de una instancia de nodejs por procesador.

Actualización (de los excelentes comentarios de Benji en la sección de comentarios sobre esta respuesta)

1. Los documentos para fread() indican que la función solo leerá hasta 8192 bytes de datos a la vez de cualquier cosa que no sea un archivo regular. Por lo tanto, 8192 puede ser una buena opción de tamaño de búfer.

[nota editorial] 8192 es es casi seguro que es un valor dependiente de la plataforma {en la mayoría de las plataformas, fread() leerá los datos hasta que el búfer interno del sistema operativo esté vacío, momento en el que volverá, permitiendo que el sistema operativo llene el búfer de nuevo de forma asíncrona. 8192 es el tamaño del búfer predeterminado en muchos sistemas operativos populares.

Hay otras circunstancias que pueden hacer que fread devuelva incluso menos de 8192 bytes for por ejemplo, el cliente "remoto" (o proceso) es lento para llenar el búfer - en la mayoría cases, fread() devolverá el contenido del búfer de entrada tal cual sin esperar a que se llene. Esto podría significar en cualquier lugar de 0..se devuelven los bytes os_buffer_size.

La moraleja es: el valor que pasa a fread() como buffsize debe considerarse un tamaño "máximo" never nunca asuma que ha recibido el número de bytes que pidió (o cualquier otro número para el caso).

2. De acuerdo con los comentarios en fread docs, algunas advertencias: citas mágicas mayo interfiere y debe estar desactivado.

3. Configuración mb_http_output('pass') (docs) puede ser una buena idea. Aunque 'pass' ya es la configuración predeterminada, es posible que deba especificarla explícitamente si su código o configuración la ha cambiado previamente a otra cosa.

4. Si estás creando un zip (en lugar de gzip), querrás usar el encabezado content type:

Content-type: application/zip

Or... se puede usar' application/octet-stream ' en su lugar. (es un contenido genérico tipo utilizado para descargas binarias de todo tipo):

Content-type: application/octet-stream

Y si desea que se le pida al usuario que descargue y guarde el archivo en el disco (en lugar de que el navegador intente mostrar el archivo como texto), necesitará el encabezado content-disposition. (donde filename indica el nombre que debe sugerirse en el diálogo guardar):

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

También se debe enviar el encabezado Content-length, pero esto es difícil con esta técnica, ya que no conoces el zip tamaño exacto por adelantado. ¿Hay un encabezado que se pueda configurar para indicar que el contenido está "transmitiendo" o es de longitud desconocida? ¿Alguien lo sabe?

Finalmente, aquí hay un ejemplo revisado que usa todas las sugerencias @ de Benji (y que crea un archivo ZIP en lugar de un TAR.Archivo 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);

Update : (2012-11-23) He descubierto que llamar a flush() dentro del bucle read/echo puede causar problemas cuando se trabaja con archivos muy grandes y / o redes muy lentas. Al menos, esto es cierto cuando se ejecuta PHP como cgi/fastcgi detrás de Apache, y parece probable que el mismo problema ocurriría cuando se ejecuta en otras configuraciones también. El problema parece ser el resultado cuando PHP descarga la salida a Apache más rápido de lo que Apache realmente puede enviarla a través del socket. Para archivos muy grandes (o conexiones lentas), esto eventualmente causa un desbordamiento del búfer de salida interno de Apache. Esto hace que Apache para matar el proceso de PHP, que por supuesto hace que la descarga se cuelgue, o se complete prematuramente, con solo una transferencia parcial que ha tenido lugar.

La solución es no para llamar a flush() en absoluto. He actualizado los ejemplos de código anteriores para reflejar esto, y he colocado una nota en el texto en la parte superior de la respuesta.