Medición del tiempo de ejecución

[suvjulen]

hola compañeros Abaperos, soy nuevo en el foro y tengo una preguntilla relacionada con la medición del tiempo de ejecución.

Mediante la SE30 se puede medir el tiempo de ejecución de un programa, pero cual debería ser la gráfica ideal para un programa, demasiada parte de abap, demasiada de acceso a base de datos.

Actualemente tengo un programa que me lleba:

28,8 de Abap
70,8 de Base de datos
0,4 de sistema.

Creo que esto se debe mejorar.

Me podeis hechar una mano?.

gracias.

[tracer]

Hola suvjulen,

Puedo observar que sois unos buenos profesionales , no todo el mundo se molesta en pasar herramientas de análisis de código después de completar los programas.

Me ha parecido tan interesante tu pregunta que he pensado que voy a escribir un artículo con las principales herramientas de análisis y optimización de sap con una pequeña overview .

Contestando a tu respuesta la verdad es que yo personalmente no puedo decirte si estos tiempos son buenos o malos sin conocer que es lo que hace el programa y cual es el tiempo total que dura su ejecución ya que solo nos has dado porcentajes relativos. Además en todo esto influyen muchos factores como nivel de llenado de tablas, tipo de tablas a las que estas accediendo (SIL,...) ....

No se quizás alguien te pueda aportar algo más.
Un saludo

[suvjulen]

MEdición del tiempo de ejecución.

Muchas gracias Tracer.

La verdad es que si que me preocupo por eso, por que estamos accediendo a 4 tablas, lo hacemos mediante uan vista genérica y en realidad el tiempo de ejecución no es excesivo, pero haciendo el trace, veo que ese select se lleba el 62% del proceso....un poco raro la verdad.

Ahora estamos en una situación ideal con pocos usuarios y pocos datos, no quiero ni pensar que pasaria en pleno apogeo....

Se trata del siguiente select:

SELECT codcsan
nhc
episodio
numpre
codcsan_4
nhc_4
codcsan_5
nhc_5
episodio_5
codcsan_6
nhc_6
episodio_6
dni
nombre
apellidos
cip
nass
tip_doc
codi_doc
direccion
poblacion
cod_postal
pais
provincia
codi_mun
telefon
sexo
fecha_nac
perfil
pac_ll_est
tipo_episodio
fecha_ing
hora_ing
fecha_alta
hora_alta
mot_alta
tipo_reg_ec
stipo_reg_ec
tipo_financ
cod_financ
cod_ccaa
cod_ccii
cod_ccee
nom_financ
cognom_financ
direccion_financ
poblac_financ
codpos_financ
provin_financ
pais_financ
telef_financ
nif_financ
numref
cod_pres
cant_pres
um_pres
prec_pres
mon_pres
est_pres
data_ini_pres
hora_ini_pres
data_fin_pres
hora_fin_pres
serv_realiz_pres
gfh_pres
obs_pres
up_org
flg_docc_pres
num_sol_ext
num_ass_urg
fac_impr_sis_ext
factura_ext
pos_factura_ext
fec_factura_ext
numped
posped
numfac
posfac
incidencia
fec_inc
hora_inc
obs_inc
usu_inc
fichact
linfichact
fecfichat
cap
un_pr_ics
un_pr_real
un_neg
pos_fact_scs
activo
FROM z27sd081
INTO TABLE g_t_repositorio
WHERE codcsan IN s_codcsa
AND data_ini_pres IN s_data
AND est_pres IN s_est_pr
AND nhc IN s_nhc
AND numpre IN so_numpr
AND un_neg IN s_un_neg
AND activo EQ space
AND tipo_reg_ec IN s_kdgrp
AND cod_financ EQ g_cliente_scs. "Inclusión de registros SCS

es un poco largo pero las normas de optimización aconsejan este tipo de selects pero no hay manera de bajar ese 62% de tiempo de ejecución total.

Mira que le hemos hecho buffering a la vista, ademas de los indices correspondientes y nada de nada.

saludos.

[tracer]

Pero es un tabla Z .

¿Cuantos registros tiene esta tabla? no debería ser un select muy pesado.

De todas formas asegúrate de acceder por campos clave y si es necesario defínete más índices. Por cierto creo que si metes todos los campos en el select de la tabla da lo mismo poner *.

Un saludo .

[SapAbapMVO]

Hola Abaperos, el codigo de tu select es bastante como te indican podrias utilizar SELECT * o el move-correspondimg. sobre el tiempo de ejecucion considero que no es mucho el tiempo, tambien depende de la maquina en la que corras SAP, cuantos mandantes existen en el, etc ... podrias apoyarte en algun Basis para despejar tu duda.
cuando trabajes con varias tablas utiliza el JOIN

Saludos desde Ecuador

[BY_MY]

Buenas compañeros.

Yo tengo un problema similar y he realizado pruebas viendo los resultados con las transacciones st05 y se30 (Tiempos de uso de la maquina y tracer). Pero al ser la primera vez que lo realizo no se muy bien que significa toda la informacion que recoje.

La cuestion es que necesito optimizar una transaccion que tarda 15 Min. y la he bajado a 7 min. pero este tiempo depende tambien de la hora a la que se lance (supongo que por cargas del sistema) de todas maneras creo que podria ser por la maquina aunque en codigo se podria optimizar un poco.


Al ser labores de mantenimiento no es sencillo el cambiar codigo y volver a construirlo todo. ¿Como podria saber si es del codigo o de la maquina? y ¿Hay algun manual que explique u oriente sobre esto?


Un saludo y muchas gracias.

[BY_MY]

Buenas compañeros.

Yo tengo un problema similar y he realizado pruebas viendo los resultados con las transacciones st05 y se30 (Tiempos de uso de la maquina y tracer). Pero al ser la primera vez que lo realizo no se muy bien que significa toda la informacion que recoje.

La cuestion es que necesito optimizar una transaccion que tarda 15 Min. y la he bajado a 7 min. pero este tiempo depende tambien de la hora a la que se lance (supongo que por cargas del sistema) de todas maneras creo que podria ser por la maquina aunque en codigo se podria optimizar un poco.


Al ser labores de mantenimiento no es sencillo el cambiar codigo y volver a construirlo todo. ¿Como podria saber si es del codigo o de la maquina? y ¿Hay algun manual que explique u oriente sobre esto?


Un saludo y muchas gracias.

[LouieBoy]

Buenas, A ver... si ejecutais una herramienta de medicion varias veces podeis haceros una idea de lo q puede tardar el programa, me explico, si ejecutas la herramienta 20 veces, y el programa tarde de entre 10 a 15 minutos (para decir algo...) entonces es "problema" del programa si el tiempo que he mencionado antes varia de 10 a 20 luego 30, 40, otra vez 20, etc.. eso significa q la ejecución es lenta por culpa de sobrecarga del sistema, es cuestión de hacer un poco de estadistica .
Otra cosa es q quieras optimizar el codigo, mirate cuantos selects-endselect hay por ahi supongo q podras recortar bastante tiempo de ejecucion.
Respecto a lo de la query veo q utilizas muchos rangos en la seleccion, esto te puede relentizar muchisimo la consulta, utilizar mas indices puede ser una buena solucion, otra idea, es intentar delimintar los rangos, como por ejemplo declararlos como obligatorios o intentar utilizar paramentros, en lugar de tanto select option, no se si utilizaras toda la clave para acceder a la tabla pero esto tambien ayuda bastante, otro recurso es utilizar una vista donde hagas una selección previa de dicha tabla donde descartes resultados que por logica no necesitas.

En fin, espero haber sido de ayuda.

Saludos.

LouieBoy

[jsanz]

Hola foro.
No llevo mucho tiempo con SAP pero me ha tocado retocar código para optimizarlo hace poco y esto es un poco lo que pude sacar en claro:

Al principio de este hilo se plantearon unos porcentajes. Navegando un poco por documentación nos dicen que estos porcentajes no deberían de exceder del 50% en el caso de sentencias ABAP y del 30% de consultas a BD, dejando el 20% al sistema.
De todas formas estos valores dependen de qué tipo de funcionalidad tenga el programa, claro está, de hecho no suele ser fácil cumplirlos en cuanto tengas unas cuantas tablas con un gran volumen de datos.

&#183;Es importante utilizar tablas internas con SELECT ... INTO TABLE <itab> y
despu&#233;s hacer LOOP en la tabla interna en vez de SELECT ... ENDSELECT.
&#183;Siempre que se pueda utilizar SELECT SINGLE ...
&#183;Es m&#225;s r&#225;pido (seg&#250;n la documentaci&#243;n) un select largo como el que se pone
m&#225;s arriba que un SELECT * (incluso aunque cojas todos los campos ).
&#183;Utilizar INNER JOIN antes que FOR ALL ENTRIES, y utilizar vistas en lugar que
INNER JOIN.
&#183;Realizar lo select por &#237;ndices o campos claves de las tablas.

Seguro que hay gente que sabe muuucho m&#225;s sobre el tema y las herramientas para solucionarlo, pero esa es mi aportaci&#243;n.
Espero que sea de ayuda.

[marcpelao]

Documento Medición Tiempo ejecución?

Hola a todos,

este es mi primer post ... He estado leyendo lo interesante de la medición del tiempo de ejecución. He entrado en las transacciones que nombráis pero no llego a entender varios conceptos. Alguien tiene algun manual sobre el tiempo de ejecución o algo?

gracias

[BY_MY]

Otra consulta,creo que tiene relacion con esto, Cuando me pongo en modo debuging por ese codigo que tengo que optimizar, si voy linea por linea me salta un dump (yo intuyo que podria ser por los tiempos de respuesta o algo asi pero no tengo ni idea). Posteo el mensaje del dump.


¿podriais decirme algo? porque me pasa a menudo que funciona una transaccion pero en modo debuggin peta



Err.tmpo.ejec. DBIF_RSQL_INVALID_CURSOR
Excep. CX_SY_OPEN_SQL_DB
Fecha y hora 04.01.2007 11:44:03



Txt.brv.
Invalid interruption of a database selection.



¿Qué ha sucedido?
Error in ABAP application program.

The current ABAP program "ZMMPR_LISTADO_BASE_CONTRATOS" had to be terminated
because one of the
statements could not be executed.

This is probably due to an error in the ABAP program.
Unable to perform database selection fully.
record.



Anál.errores
An exception occurred. This exception is dealt with in more detail below
. The exception, which is assigned to the class 'CX_SY_OPEN_SQL_DB', was
neither
caught nor passed along using a RAISING clause, in the procedure
"SELECCIONAR_DATOS" "(FORM)"
.
Since the caller of the procedure could not have expected this exception
to occur, the running program was terminated.
The reason for the exception is:
One of the database selections included a database commit.
The selection was then supposed to continue. Before a
database commit, however, all outstanding database selections must be

[LouieBoy]

Hola, Esto es pq estas debuggeando una sentencia SELECT... ENDSELECT.
Cuando estas manejan un gran volumen de datos al hacer debuggin peta...
Es uno de los inconvenientes de usar este tipo de instruccion, por eso siempre q puedo vuelco todo el select sobre una tabla interna y luego hago un loop sobre esta y realizo las operaciones q necesite.

Saludos,

LouieBoy

[BY_MY]

ok gracias. Eso que dices es lo que estoy haciendo pero no por el debbuging sino por repartir las cargas ya que tira casi todo de BB.DD. incluso en select endselect anidados y los estoy pasando a loop at de tablas internas.

Parece ser que asi aumenta el rendimiento.



Muchas gracias y feliz año.

[cosmica]

Performance

Gente: Algunos Tips sobre performance:

- Evitar logica negativa en los selects.
- No utilizar OR's en los SELECTS.
- Utilizar APPEND LINES OF i_tab para unidir dos tablas internas.
- Evitar el loop where, utilizar mejor loop check.
- Evitar el into corresponding fields of table, utilizar into table (poner los campos en el mismo en que fueron definidos en la tabla interna).
- Cuando accedan a tablas transparentes como las MARA, y demas que generalmente contienen muchisimos datos, eviten de ser posible los inner join, porque llevan muchisimo tiempo, traten de realizar selecciones separadas a distintas tablas internas y las unen por alguna tecnica de posicionamiento.
- No utilizar select * a menos que levanten mas del 70% de los campos que tiene la tabla.

Espero que les sirva!
Saludos,

[javibest]

Hola, Esto es pq estas debuggeando una sentencia SELECT... ENDSELECT.
Cuando estas manejan un gran volumen de datos al hacer debuggin peta...
Es uno de los inconvenientes de usar este tipo de instruccion, por eso siempre q puedo vuelco todo el select sobre una tabla interna y luego hago un loop sobre esta y realizo las operaciones q necesite.

Saludos,

LouieBoy

De eso no estoy totalmente seguro . Puede ser que dentro del select enselect haya introducido un commit work and wait , y puede ser debido a esto por lo que salta el dump .