agilizar listados mediante buffer

[verinchi]

Hola gente.
Tengo más tiempo trabajando con ASP que con symfony y me encuentro en el inconveniente que, para resolver consultas que devuelven muchos resultados, me da overflow de memoria.
Con ASP utilizaba la sentencia response.buffer que lo que hacía era justamente, mediante el uso de buffer, ir mostrando los resultados a medida que la db los resolvía, sin esperar a cargar toda la consulta en la memoria.
De este modo, si bien el listado iba incrementando a medida que el script pasaba datos al navegador, la memoria no se saturaba y el usuario no quedaba media hora con una pantalla en blanco, esperando respuesta.
En Symfony, alguien conoce algo similar como para agilizar el muestreo de consultas con muchos resultados, o páginas con muchos renderizados de otros controladores que hacen consultas independientes?
He buscado en manuales y sitios pero no di con ninguno que trate el tema.

Desde ya, mil gracias por la orientación que me puedan dar.

[hhs]

Creo que esto te puede servir: https://doctrine-orm.readthedocs.org...ata-processing

[verinchi]

hola Hhs, gracias por tu respuesta.

Verás, en realidad no es lo que estoy buscando, ya que no necesito procesar los datos de mis consultas sino agilizar las muestras.

Tengo un reporte diseñado más o menos de la siguiente forma:

reporte.html.twig

{{dato1}}{{dato2}}

render controller('funcion1', {'var1':variable})
render controller('funcion2', {'var1':variable})
render controller('funcion3', {'var1':variable})

en cada uno de estos controladores, ejecuto una consulta diferente a la DB que devuelve n resultados cada una, para los cuales, envío a renderizar un html diferente en cada caso, comos ser:

funcion1Action($var1){

$resultado=$em->getRepository('clase')->find($var1);
retorno resultados con render('ubicacionarchivo.html.twig', array('datos'=>$resultado));

}

Y así, unas 15 veces con diferentes consultas que van incluidas en un reporte.

Esto genera que se sature la memoria y no estoy encontrando la forma de alivianarlo un poco.

[hhs]

Cual es la razón de hacer eso con tres controllers ?
Creo que puedes hacer un solo controller y usar el repository para una consulta.
Lo demás es que hagas caching del Result set y de la vista final.
Referencias:
http://symfony.com/doc/current/book/http_cache.html
http://docs.doctrine-project.org/en/...e/caching.html
http://symfony.com/doc/current/refer.../doctrine.html

[verinchi]

Hola hhs. Gracias por tu respuesta.
Lo hago de esta forma porque se trata de un reporte que tiene la siguiente estructura:
Consulto según origen y un rango de fechas, los trámites que se ingresaron.
Para cada trámite comprendido en ese rango, tengo que mostrar:
- textos básicos correspondientes a cabecera y descripción, obtenidos mediante una consulta a 5 tablas para decodificar el tipo de trámite, tipo de origen y algunos datos más almacenados en la forma Código/Descripción.

- Responsables del trámite, de 1 a n almacenados en una tabla diferente que también tiene datos que deben consultarse en otras tablas para decodificarlos.

- Fechas de Ingreso y Egreso en distintos departamentos, también de 1 a n, debiendo joinear para conseguir la descripción del departamento.

- Fechas de ingreso y egreso a departamentos secundarios. Igual a la anterior pero con otras tablas.

- Fechas de ingreso y egreso a oficinas, lo mismo que la anterior con otras tablas.

- Si la ultima oficina en la que ingresó fue archivo, hay que buscar en otra tabla unas fechas de caducidad, armando unas leyendas.

- Una consulta a los subtrámites generados del trámite que se obtiene consultando unas 7 tablas con datos de estos subtrámites.

- Una consulta para fecha de despacho y coordinaciones cuyos datos están en otras dos tablas.

- Una consulta para resoluciones del trámite con pase a oficinas internas, datos que también se consultan en otras tablas.

- Una consulta de resolución con pase a directivos, observaciones y agregado de directivos y circular (Fecha y datos de la circular)

- Una consulta a una tabla que tiene datos de rechazo y recomienzo del trámite, para los casos que haya sucedido que el trámite se cancele por alguna razón y se haya vuelto a comenzar. Datos de la cancelación y motivos del recomienzo.

- Una consulta a Autoridades Varias que participaron de alguna manera en el trámite (Con detalles)

- Observaciones generales del trámite en el pie de página, que se obtiene de la consulta principal.

Como cada Item de cada trámite debe buscarse en tal diversidad de tablas, realizarlo con una sola consulta es un poco inconveniente porque por cada entidad trámite tendría que ir a buscar (Muchas veces de forma condicional) n cantidad de otras entidades.
Por eso utilizo renderizaciones de las consultas secundarias por cada vuelta del bucle sobre la entidad principal Trámite.
Además, enviar todo ese conjunto de datos a la caché para después salir a mostrarlos consumiría muchísimo tiempo y memoria.

Lo que necesito y no estoy consiguiendo, es utilizar la caché como puente para ir devolviendo los datos al navegador a medida que los recibo de la consulta, sin esperar a tener todo el conjunto resuelto para comenzar a muestrear los datos. No se si me explico :/

[hhs]

Vaya si que esta enorme el reporte Cual es el volumen de datos aprox. ?
Debes de considerara pasar esto a un Procedimiento en la base de datos y crear un comando para que lo ejecutes de forma programada; de esta forma no entorpeces el flujo en la aplicación.

[verinchi]

Qué mas quisiera que hacer procedimientos!!! Más aún utilizando la potencia de Oracle, pero... la vida del programador no suele ser sencilla y los DBA están empecinados en que no hagamos vistas, ni procedimientos, ni funciones

No tiene sentido, es una batalla que seguramente perderán pronto pero... por ahora hay que arreglarselas como se pueda.

Ya pasaré a comentar si encuentro alguna forma de agilizar este reporte, por ahora sin novedades :)

Gracias por tu respuesta!

[witchy]

Hola, se me presento el mismo problema hace poco tiempo, no pude resolverlo optimizando la cache, ni ampliando la memoria del servidor, mi solucion temporal fue no cargar los datos completos y utilizar buscadores, si encuentran una solucion ma optima me gustaria verla. Saludos

[verinchi]

Hola, después de darle muchas vueltas pude optimizar un poco los tiempos de respuesta con lo siguiente:

Código PHP:

   $em->getConnection()->getConfiguration()->setSQLLogger(null);  
   

Con esto lo que hago es inhabilitar el logger por defecto, quitando carga de procesamiento. Lo que hay que tener en cuenta es que con esto, si queremos ver la consulta que va a la base de datos, no podremos mediante la consulta del profiler ya que no la logueará.

Código PHP:

  $em->clear();  
   

Antes de realizar el return, libero el entity manager

Código PHP:

  ini_set('implicit_flush',1); 
        ini_set("memory_limit", "1024M"); 
        ini_set('max_execution_time', 120);  
   

Esto lo coloco antes de cualquier instrucción de cada función para activar el flush implícito, aumentar la memoria y el tiempo de ejecución.

Con esto, evité en mi caso la mayoría de los overflows y timeouts. Luego coloqué algunas restricciones en las búsquedas, como ser que no se pueda consultar para más de un año (12 meses) la información, para limitar un poco la cantidad de registros a listar cada vez.

Espero que a alguien le sirva, saludos!