[SOLUCIONADO] Ejecutar query que demora más de 4000MS (postgresql)

[oggy_15_3]

Hola a todos,
Quería saber como puedo ejecutar querys en las que el resultado demora más de 4000ms.

Intenté usar el ini_set("memory_limit","1024M") de php, pero no he logrado que me cargue el query.

Mi query esta compuesto por varias tablas relacionadas, es un reporte muy importante para mi cliente, todo funcionaba bien, antes el resultado demoraba 323ms como máximo ahora supera los 4000ms, esto se debe a que hay 2 nuevos registros, por estos 2 nuevos registros es que demora su carga desde php.

¿Alguien ha podido dar solución a esto?
Hay una línea en el php.ini que permite aumentar el recurso de la memoria para la aplicación si no me equivoco, el tema es que el servidor esta en centos y no tengo acceso a ello, ¿Alguna otra alternativa?

Saludos.

[gnzsoloyo]

Dos registros no pueden generar semejante demora. Es evidente que hay problemas con la sintaxis de la consulta, o bien los la estructura de datos. En cualquier caso es un tema OFF TOPIC en PHP y deberías preguntar en el foro de PostgreSQL, posteando la query, porque sin verla es imposible hacer un diagnóstico.

PHP no va a solucionar nada, porque no interpreta SQL, ni lo entiende.

[oggy_15_3]

Iniciado por gnzsoloyo

Dos registros no pueden generar semejante demora. Es evidente que hay problemas con la sintaxis de la consulta, o bien los la estructura de datos. En cualquier caso es un tema OFF TOPIC en PHP y deberías preguntar en el foro de PostgreSQL, posteando la query, porque sin verla es imposible hacer un diagnóstico.

PHP no va a solucionar nada, porque no interpreta SQL, ni lo entiende.

Quizás me equivoque, pero considero que debe estar posteado en php
ya que desde el pgadmin de postgresql la query sólo demora 5seg. en su carga.

Gracias por tu consejo, pero discrepo con lo de postearlo en el foro de POSTGRESQL por lo siguiente:
- Siempre habrá querys en la que el resultado demoré más de 5 segundos (el mio demora en sí 6seg), por ello no lo pongo en la sección de postgresql, considero que el problema estaría en php y que quizás haya la manera de aumentar el tiempo de respuesta de la consulta hecha (memoria). Hay queerys muys complejas que considero php puede cargar, como esta.

El query que uso es el siguiente:

Código MySQL:

SELECT ot.fec_inic,(case ns.cdg_tpg when '002' then '/S' else '' end)AS cdg_tpg,ns.num_guia, 
to_char(ns.fec_guia, 'Month')AS let_mes,date_part('month',ns.fec_guia)AS num_mes, to_char(ns.fec_guia,'dd-mm-YYYY')AS fec_guia,prd.des_prod,
ROUND(nsd.can_dgui,4) AS can_sal, '0' AS can_dev, nsd.can_dgui AS can_cons, 
ROUND((case ns.cdg_mon when '001' then nsd.pre_guia else (case 001 when '002' 
then nsd.pre_guia/tcmb.tip_cmb else nsd.pre_guia*tcmb.tip_cmb end)end)::numeric,4)AS cto_unit, 
ROUND((nsd.can_dgui*(case ns.cdg_mon when '001' then nsd.pre_guia else (case 001 when '002' 
then nsd.pre_guia/tcmb.tip_cmb else nsd.pre_guia*tcmb.tip_cmb end)end)),4)AS cto_tot,nsd.cdg_prod, 
LEFT(nsd.cdg_prod,3)AS familia, ot.num_otrb,otd.cdg_prod AS cdg_prod_int, ns.cdg_mon,tcmb.tip_cmb,(case 001 when '002' then 'US$' else 'S/.' end) AS sigla_moneda 
FROM m_ordtrb ot 
INNER JOIN d_ordtrb otd ON otd.num_otrb=ot.num_otrb 
INNER JOIN m_guia ns ON (ns.num_otrb=ot.num_otrb AND ns.cdg_tpg='002' AND ns.swt_est<>'A') 
INNER JOIN d_guia nsd ON (nsd.num_guia=ns.num_guia AND ns.cdg_tpg=nsd.cdg_tpg) 
INNER JOIN p_guia mat ON (mat.num_guia=ns.num_guia AND (mat.cdg_term=otd.cdg_prod AND mat.cdg_prod=nsd.cdg_prod 
AND mat.num_otrb=ot.num_otrb AND mat.num_otrb=ns.num_otrb) ) 
INNER JOIN t_cambio tcmb ON tcmb.fec_cmb=ns.fec_guia 
INNER JOIN m_produc prd ON prd.cdg_prod=nsd.cdg_prod 
WHERE ot.swt_apr=1 AND(ot.fec_inic>='01-3-2015' AND ot.fec_inic<='31-3-2015') 
AND ((ot.num_otrb='') OR (ot.num_otrb='0200001281' AND otd.cdg_prod 
IN('7676100697','7676100698','7676100699','7676100700','7676100701','7676100702','7676100703','7676100704','7676100705'))) 
ORDER BY ns.fec_guia,ns.num_guia
 

Las condicionales del query pueden varias en fechas y num. orden de trabajo.

Y si estoy equivocado en lo que redacto, mil disculpas, pero quiero aferrarme un poco a que el problema estaría en php.

Saludos!.

[gnzsoloyo]

OK. Ahora una pregunta simple para ti: ¿En que forma consideras que PHP puede hacer que una consulta en la base de datos aumente o disminuya su tiempo de ejecución dentro del DBMS?
Por supuesto, partiendo de la base cierta que PostgreSQL es una sistema completamente independiente y autónomo del lenguaje que lo invoca, ya que no existe integración entre ambos... supongo que eso si lo sabes, ¿no?

[oggy_15_3]

Iniciado por gnzsoloyo

OK. Ahora una pregunta simple para ti: ¿En que forma consideras que PHP puede hacer que una consulta en la base de datos aumente o disminuya su tiempo de ejecución dentro del DBMS?
Por supuesto, partiendo de la base cierta que PostgreSQL es una sistema completamente independiente y autónomo del lenguaje que lo invoca, ya que no existe integración entre ambos... supongo que eso si lo sabes, ¿no?

Lo mencioné en mi primer post y no mencioné en disminuir el tiempo de ejecución sino que el tiempo de espera de la consulta no muestre un error cuando la consulta demora más de lo normal.

Gracias de todas maneras por responder.

[gnzsoloyo]

Eso es configura le, pero no esta relacionado con la memoria, sino con el timeout. Asignarle más memoria no lo evitará.
En ese tema la cosa pasará por si en el host donde finalmente funcionará tu aplicación es tuyo o será un host compartido (tercerizado), porque necesitas permisos especiales para modificar el archivo de configuración de PHP.

[xfxstudios]

prueba colocando esto en tu consulta:

Código PHP:

set_time_limit(0);
 

[Fleon]

¿Y los índices?, los índices tienen mucho que ver con la velocidad de procesamiento, verificar si en cada campo donde realizas un inner,lefts y rights joins tienen sus indices, sino intenta agregarlos y verás la diferencia.

Saludos.

[oggy_15_3]

Iniciado por Fleon

¿Y los índices?, los índices tienen mucho que ver con la velocidad de procesamiento, verificar si en cada campo donde realizas un inner,lefts y rights joins tienen sus indices, sino intenta agregarlos y verás la diferencia.

Saludos.

Lamentablemente, la base de datos no la cree yo, yo sólo estoy implementando reportes web a través de php y extrañamente esa base de datos no maneja indices en sus campos.

[oggy_15_3]

Iniciado por gnzsoloyo

Eso es configura le, pero no esta relacionado con la memoria, sino con el timeout. Asignarle más memoria no lo evitará.
En ese tema la cosa pasará por si en el host donde finalmente funcionará tu aplicación es tuyo o será un host compartido (tercerizado), porque necesitas permisos especiales para modificar el archivo de configuración de PHP.

La aplicación esta en el servidor propio de un cliente y conozco a la persona que puede modificar el archivo php.ini si lo del timeout podría ser la solución.

¿Recuerdas que línea del archivo php.ini se debe editar?
Me llama la atención la siguiente línea:

max_execution_time = 30
default_socket_timeout = 60

Quería hacer mis pruebas localmente con la base de datos actual, pero llevo 2 veces intentando sacar el backup y no he podido. El backup me sale incompleto, eso a pasado recientemente. Intentaré generarlo un par de veces más ya que hoy nadie trabaja.


Gracias.

[xfxstudios]

brother prueba con esto:

Código PHP:

set_time_limit(0);
 

ya que asi el archivo se salta la restricción del php.ini y tarda lo que tenga que tardar, asi dejar la limitacion que es necesaria para otros procesos, yo utilizo esa linea en algunos formularios donde tienen que cargar algun archivo adjunto, ya que hay casos en los que si la conexion a internet esta lenta el procesa caducaba durante la carga del archivo

[oggy_15_3]

Iniciado por xfxstudios

brother prueba con esto:

Código PHP:

set_time_limit(0);
 

ya que asi el archivo se salta la restricción del php.ini y tarda lo que tenga que tardar, asi dejar la limitacion que es necesaria para otros procesos, yo utilizo esa linea en algunos formularios donde tienen que cargar algun archivo adjunto, ya que hay casos en los que si la conexion a internet esta lenta el procesa caducaba durante la carga del archivo

Sry, olvidé responderte.
Siempre he trabajado con el set_time_limit(0); en procesos como este, pero el resultado nunca me termina de cargar.
Gracias de todas maneras.

[Triby]

La directiva a cambiar en php.ini es max_execution_time. Podrías ponerlo a cero para que no haya límite de tiempo, aunque existe el riesgo de que un script se quede colgado y tengas que recurrir a otras cosas para terminarlo.

Ahora, si tienes acceso a la base de datos... crea los índices necesarios!!!! con esto te vas a evitar problemas posteriores.

[Fleon]

Iniciado por oggy_15_3

Lamentablemente, la base de datos no la cree yo, yo sólo estoy implementando reportes web a través de php y extrañamente esa base de datos no maneja indices en sus campos.

Pues lamentablemente alguien tiene que crearlos, y sí esa base de datos maneja índices:

Código SQL:

CREATE INDEX I_tabla_campo ON tabla(campo);
 

Saludos.

[gnzsoloyo]

Manual de referencia:

max_execution_time

Este valor establece el tiempo máximo en segundos que se permite ejecutar antes de que el analizador termine. Esto ayuda a prevenir que scripts mal escritos bloqueen el servidor. El valor por defecto es 30. Cuando se ejecuta PHP desde la línea de comandos el valor por defecto es 0.

El tiempo de ejecución máxima no está afectada por llamadas al sistema, operaciones de stream etc. Por favor véase la función set_time_limit() para más información.

No se puede cambiar esta opción con ini_set() cuando se ejecuta en modo seguro. La única manera es desactivar safe mode o cambiando el límite en php.ini.

El servidor web puede tener otras configuraciones de tiempo de espera que quizá interrumpan la ejecución de PHP. Apache tiene la directiva Timeout y IIS tiene la función CGI timeout. Las dos de 300 segundos por omisión. Véase la documentación del servidor web para información específica.


max_input_time

Establece el tiempo máximo en segundos que se permite a un script analizar datos de entrada, como POST y GET. La medición comienza en el momento en que PHP es invocado en el servidor y finaliza cuando la ejecución comienza.

[oggy_15_3]

Acabo de crear un archivo php de prueba en la que ejecuto el query que deje más arriba y para sorpresa demora un poco en mostrar el resultado, pero sí lo muestra.
La única diferencia entre el archivo de prueba y el archivo php (original) donde tengo mi reporte es que la petición lo hago a través de AJAX.
Desconozco si tiene algo que ver que la petición lo haga a través de ajax, ya que el resultado se muestra en una tabla (modelo reporte) y lo visualizo en alguna parte de una página principal del sistema en sí.

[oggy_15_3]

Llevo tiempo usando jquery-ajax y olvidé por completo que hay un parámetro
al momento de hacer las peticiones a través de AJAX llamada timeout (para sorpresa el mismo nombre que se usa en php) y pues la solución fue ponerlo en 0.

Gracias a todos por la ayuda, el problema estaba en la petición a través de AJAX. (se me chispoteo .__.')

[Triby]

Que funcione no quiere decir que lo hayas solucionado, solo tapaste un bache, pero pueden presentarse otros muchos a futuro!