Tutorial ABAP (en español) – 

Rendimiento
1         RENDIMIENTO
 

1.1       DEMOS DE RENDIMIENTO

En SAP existen ejemplos prácticos con demostraciones sobre programación
eficiente a los que se puede acceder desde la transacción SE80.  Estos
ejemplos cubren la mayor parte de las sentencias ABAP que
potencialmente pueden llegar a consumir mucho tiempo.

En general conviene tener presente que el código más eficiente que existe
es aquel que nunca se escribe porque nunca consumirá tiempo de CPU,
nunca tendrá un bug y nunca será necesario mantenerlo.

1.2       DIAGNÓSTICO
Como programadores siempre vamos a tener una ventaja evidente sobre
otros profesionales, siempre vamos a poder demostrar si nuestras teorías
son ciertas o no. La transacción SAT nos permite hacer un análisis de
rendimiento de una transacción o programa. Para ello basta con ir a la SAT,
indicar el programa, ejecutarlo, introducir los parámetros de selección o
interaccionar con él del mismo modo en el que lo haríamos habitualmente y
al finalizar el programa tendremos un detalle pormenorizado de cuánto
tiempo está consumiendo cada acción en el código.
Solo nos tenemos que fijar en la columna Net [%]. Si detectamos líneas con
un net > 10%, esos y solo esos serán los puntos que deberemos optimizar, y
además nos permite priorizar los más críticos. Tras cada mejora en el
código volvemos a ejecutar la SAT para ver si realmente es una mejora y en
caso de que lo sea, cuál es la nueva prioridad ahora.

1.2.1      POSIBLE CAUSA 1: SENTENCIAS SQL

La causa más común de un mal rendimiento son los SELECTS a tablas muy
grandes (MKPF, MSEG, BSEG…). Estas tablas crecen exponencialmente
con el tiempo y leer registros de ellas se vuelve muy lento. Por su diseño, el
rendimiento solo suele ser aceptable leyendo entradas por índice o
restringidos a muy pocas entradas (idealmente una solo con SELECT
SINGLE).
 En la mayoría de los programas esta es la parte más lenta ya que requiere
leer físicamente un disco curo, lo cual es del orden de unas 100 veces más
lento que leer de la memoria RAM. En la medida de lo posible, las
operaciones pesadas se deben hacer en memoria y no en la base de datos (el
SELECT)

1.2.2      POSIBLE CAUSA 2: CÓDIGO ABAP: BUCLES ANIDADOS

La otra posible causa es tener bucles (LOOP, READ TABLE, SELECTS
ANIDADOS, FOR ALL ENTRIES) muy poco optimizados. Si por ejemplo
tenemos 2 tablas con 1000 registros cada una y queremos encontrar los
registros de una que coinciden en la otra mediante LOOPS anidados, y cada
operación tardase 1µs, completar la tarea requerirá 1000*1000*1 = 1
segundo. Si la segunda tabla fuese de tipo hashed y ordenada por la
condición adecuada habría tardado 1000*1*1 = 1ms.

Puede parecer que 1 segundo no es mucho pero ¿y si las tablas tuviesen

10.000 registros cada una? De repente hablaríamos de casi 17 minutos para
completar la tarea.

No se trata solo de lo que tarda sino de la velocidad con la que los tiempos
escalan. ¿Si las tablas siguen creciendo, cuando se ralentizará mi programa
dentro de 5 años? Por eso en lugar de tiempo absoluto, en programación se
emplea la notación-O para hablar de si un programa es rápido o lento.

1.3       NOTACIÓN-O
Atendiendo a su complejidad, las notaciones Big-O más comunes para todo
tipo de algoritmos y funciones son las que se muestran en esta lista:

 O(1): constante. La operación no depende del tamaño de los datos. Es el

caso ideal, pero a la vez probablemente el menos frecuente. No se ve en la
gráfica de más abajo porque la logarítmica le pasa justo por encima y la
tapa.
 O(n): lineal. El tiempo de ejecución es directamente proporcional al
tamaño de los datos. Crece en una línea recta.
 O(log n): logarítmica. por regla general se asocia con algoritmos que
“trocean” el problema para abordarlo, como por ejemplo una búsqueda
binaria.
 O(nlogn):en este caso se trata de funciones similares a las anteriores, pero
que rompen el problema en varios trozos por cada elemento, volviendo a
recomponer información tras la ejecución de cada “trozo”. Por ejemplo, el
algoritmo de búsqueda Quicksort.
 O(n2): cuadrática. Es típico de algoritmos que necesitan realizar una
iteración por todos los elementos en cada uno de los elementos a procesar.
Por ejemplo el algoritmo de ordenación de burbuja. Si tuviese que hacer la
iteración más de una vez serían de complejidad O(n3), O(n4), etc… pero se
trata de casos muy raros y poco optimizados.
 O(2n): exponencial. Se trata de funciones que duplican su complejidad con
cada elemento añadido al procesamiento. Son algoritmos muy raros pues en
condiciones normales no debería ser necesario hacer algo así. Un ejemplo
sería, por ejemplo, el cálculo recursivo de la serie de Fibonacci, que es muy
poco eficiente (se calcula llamándose a sí misma la función con los dos
números anteriores: F(n)=F(n-1)+F(n-2)).
 O(n!); explosión combinatoria. Un algoritmo que siga esta complejidad es
un algoritmo totalmente fallido. Una explosión combinatoria se dispara de
tal manera que cuando el conjunto crece un poco, lo normal es que se
considere computacionalmente inviable. Solo se suele dar en algoritmos
que tratan de resolver algo por la mera fuerza bruta. No deberías verlo
nunca en un software “real”.
 Podemos verlo gráficamentea continuación:
En el eje horizontal tenemos el número de elementos, y en el vertical el
tiempo.

Como podemos observar, a medida que aumenta la complejidad, el

tiempo necesario para completar la tarea crece mucho, pudiendo llegar
a aumentar enormemente en algunos casos en cuanto hay más datos a
manejar. Creo que verlo gráficamente es la mejor manera de darse cuenta
de su importancia.
Si te encuentras con una función con complejidad cuadrática (O(n2)) o
exponencial (O(2n)) por regla general será señal de que el algoritmo
necesita una revisión urgente, y mejor no utilizarlo.
Lo interesante de esta notación es que nos permite comparar varios
algoritmos equivalentes sin preocuparnos de hacer pruebas de
rendimiento que dependen del hardware utilizado. Es decir, ante
resultados equivalentes podemos elegir el algoritmo de mayor rendimiento,
que lo será siempre independientemente del hardware si el conjunto de
datos es lo suficientemente grande (en conjuntos pequeños un hardware
más rápido puede dar resultados más rápidos para un algoritmo menos
eficiente, pero a medida que el conjunto crece ya no será así).
Por eso, a partir de ahora, cuando veas que una función documenta
explícitamente su

 
1.4       ARREGLAR PROBLEMAS CON LAS
SENTENCIAS SQL
 

1.4.1      Índice primario

La clave primaria de una tabla la forman aquellos campos para los que los
registros son unívocos. Pongamos que tuviésemos una tabla con los campos
(‘año’, ‘mes’ y ‘días’) donde guardásemos el número de días de cada mes.
Para una única combinación año + mes la respuesta debería ser única
(Febrero + 2016) = 29 días. Si en la tabla tuviésemos más adelante otra
entrada (Febrero + 2016) = 28 días, sería incoherente, ya que un mes no
puede tener 2 duraciones.

Sin embargo sí que podría tener (Febrero + 2015) = 28 ya que no es la

misma clave (cambia uno de sus campos).

Solo existe una clave (índice primario) por tabla.

1.4.2      Índices secundarios

La tabla se guarda en la base de datos ordenada en base a su clave primaria
para acelerar búsquedas en base a un ÍNDICE PRIMARIO. Existen
también ÍNDICES SECUNDARIOS que se emplean sobre todo en tablas
con muchos campos en los que la búsqueda (la cláusula WHERE) coincide
habitualmente con otra combinación de campos que no es la clave primaria.
Llegados a este punto puedo explicar mejor la diferencia entre las tablas
SORTED y HASHED y por qué estas últimas son todavía más eficientes.
Las tablas HASHED tienen necesariamente definida una clave única y se
busca en ellas siempre empleando la clave primaria. Las tablas sorted
permiten que la clave no sea única y simplemente lo que define es por qué
campos se va a ordenar la tabla.

1.4.3      Tablas puente

 Pongamos que queremos obtener las entregas de un pedido. La tabla VBAP
contiene las posiciones de las entregas y el pedido figura allí (campos 
VGBEL y VGPOS). El problema es que esos campos no forman parte de
ningún índice y sin embargo son nuestra condición de selección (cláusula
WHERE)

Podríamos pensar en crear un nuevo índice secundario, aunque en tablas Z

por lo general no hay problema, las tablas estándar ya contienen
normalmente un número mayor de índices. Cada índice adicional que
creemos nos hará ganar tiempo en las lecturas específicas que se hagan
restringiendo por los campos de ese índice, pero como contrapartida, cada
escritura que se haga en esa tabla será un poco más lenta porque es
necesario regenerar de nuevo todos los índices tras cada modificación y
ahora hay más índices que regenerar.

En esta tabla (y no es la única) existe una estrategia mejor. Existe la tabla

VBFA que guarda las relaciones entre documentos de venta previos y
subsiguientes, que podemos utilizar como ‘puente’ entre el pedido y la
entrega. En la clave primaria de esta tabla sí que tenemos el pedido como
entrada y obtendríamos con ello el número de entrega que nos permitiría
acceder por índice a la VBAP.

Ejemplo:

1. Accesses to sales orders (tables VBAK, VBAP)

a) Búsqueda a través del cliente (campo VBAK-KUNNR):

Lento:
SELECT FROM vbak WHERE kunnr = …
Mejor:
SELECT FROM vakpa WHERE kunde = …
SELECT FROM vbak WHERE vbeln = vakpa-vbeln.

b) Búsqueda a través del material (campo VBAP-MATNR):

Lento:
 SELECT FROM vbap WHERE matnr = ...

Mejor:

SELECT FROM vapma WHERE matnr = ...    

SELECT FROM vbap WHERE vbeln = vapma-vbeln

                   AND posnr = vapma-posnr

1.4.4      Base de datos: lectura de índices

Pongamos como ejemplo una tabla (MSEG) que tiene un definido un índice
con los siguientes campos:

Índice ‘Z05’: (MATNR + WERKS + BWART + CHARG + AUFNR)

 Matnr – Material
 Werks – Centro
 Bwart – Tipo de movimiento
 Charg – Número de lote
 Aufnr – Orden
 

Ejemplo 1 – Clave completa:

SELECT * FROM MSEG INTO CORRESPONDING FIELDS OF
TABLE li_datos

WHERE matnr = pi_matnr

   AND werks = ‘PEO1’

     AND bwart in lr_bwart

      AND charg = ‘A’

     AND aufnr = pi_aufnr.

En este ejemplo, la clave se suministra completa, la base de datos empleará

este índice para seleccionar la información y el acceso será rápido.

Ejemplo 2 – Sin clave:

WHERE  werks = ‘PEO1’

        AND bwart in lr_bwart

        AND charg = ‘A’

        AND aufnr = pi_aufnr.

Los índices están ordenados, de modo que si nos dejamos de suministrar un

solo componente, los siguientes campos del índice no serán tenidos en
cuenta. Este caso es equivalente a seleccionar la tabla completa en la base
de datos y recorrerla entera probando registros  registro si cumple las
condiciones. Es muy lento.

Ejemplo 3 – Con clave parcial:

1. A) Falta un campo
WHERE matnr = pi_matnr

  AND werks = ‘PEO1’

  AND charg = ‘A’

   AND aufnr = pi_aufnr.

Como falta bwart, esto es equivalente desde el punto de vista del

rendimiento a restringir solo por matnr + werks. Eso se utilizará la
seleccionar un trozo de la tabla y a continuación se recorrerá ese trozo
registro a registro evaluando el resto de condiciones.

1. B) Hay una condición negativa

WHERE matnr = pi_matnr

  AND werks <> ‘PEO1’

  AND bwart in lr_bwart

  AND charg = ‘A’

  AND aufnr = pi_aufnr.

Las condiciones negativas (<>, not in …) no permiten emplear los índices.

Lo expuesto anteriormente es equivalente a leer el índice con clave parcial
(solo matnr)

Ejemplo 3 – Con clave + campos adicionales:

WHERE matnr = pi_matnr

  AND werks = ‘PEO1’

  AND bwart in lr_bwart

  AND charg = ‘A’

  AND lgort = pi_lgort.

  AND aufnr = pi_aufnr.

En este caso, se suministra también el campo lgort (almacén). En este caso

lo que hará será emplear el índice para seleccionar los registros y a
continuación recorrerlos uno a uno aplicando esta condición.

Dado que estas operaciones tienen lugar en la base de datos (lento) a

menudo es más eficiente realizar estas operaciones en un paso posterior en
memoria:

SELECT * FROM MSEG INTO CORRESPONDING FIELDS OF

TABLE li_datos

WHERE matnr = pi_matnr

  AND werks = ‘PEO1’

  AND bwart in lr_bwart

  AND charg = ‘A’

  AND aufnr = pi_aufnr.

DATA: li_datos_sorted TYPE SORTED TABLE OF

ty_datos WITH NON-UNIQUE KEY lgort.

li_datos_sorted = li_datos.

DELETE li_datos WHERE lgort = pi_lgort.

 
Donde para que sea rápido, li_datos deberá ser una tabla ordenada por el
campo lgort. El DELETE tiene lugar ya en nuestro equipo en memoria y no
en el servidor de SAP (base de datos) de modo que es mucho más rápido.
Aquí no importa expresar las condiciones en negativo ya que nos
aprovechamos de que la tabla esté ordenada pero en memoria no estamos
consultando ningún índice.

Las operaciones de ordenar (SORT o implícitas como cuando se copia el

contenido de una tabla estándar a una tabla ordenada) son también más
rápidas en memoria que en la base de datos con una excepción, si el orden
es el de la clave, la base de datos ya guarda los campos ordenados por lo
que no le cuesta tiempo adicional hacerlo.

1.4.5      Optimizador SQL: cómo funciona la base de datos

Cuando en el WHERE hay campos de varios índices distintos, el
optimizador de la base de datos es el que decide qué índice debe utilizar.
Para ello emplea un algoritmo basado en el coste para estimar cuál de las
opciones será más eficiente. No intenta emplear aquel índice del que le
hayamos proporcionado más información sino aquel que sea más restrictivo
y que por tanto devuelva el menor número posible de campos tras filtrar
solo por las condiciones de los campos del índice. A continuación, con esos
registros ya seleccionados, aplicará el resto de las condiciones del WHERE.

Para que el optimizador decida emplear un índice, la selectividad del índice

debe ser menor al 10%. Dicho de otra forma, si tenemos una tabla con:

1000 registros

999 cumplen werks = ‘PEO1’

1 cumple werks = ‘PFV1’

En este caso, aunque específiquemos WHERE werks = ‘PEO1’ y sea este el
primer campo de la clave primaria, el optimizador va a ignorar el índice y
va a proceder a leer la tabla completa (full-scan). EL motivo es que aun
consultando el índice, va a seleccionar el 99’9% de los registros, muy por
encima del 10%. Dado que consultar el índice es como leer una tabla
intermedia y también tiene un coste, el optimizador decidirá que es más
rápido ignorar el índice y leer la tabla al completo.

Cuanto más complejas sean las cláusulas del where, más difícil es para el
optimizador encontrar la estrategia óptima.

1.4.6      Valores únicos (SELECT SINGLE)

En ocasiones no querremos obtener todos los valores que cumplen una
condición sino solo comprobar si existe al menos uno. Un ejemplo puede
ser para comprobar si un material se ha recepcionado alguna vez, en cuyo
caso buscaremos documentos de material pero con encontrar uno nos
bastará para averiguarlo, no los necesitamos todos.

SELECT * FROM MSEG INTO CORRESPONDING FIELDS OF

TABLE li_datos

WHERE …

–>

SELECT SINGLE* FROM MSEG INTO CORRESPONDING FIELDS

lw_datos

WHERE …
Como el resultado es un único registro se copia en una estructura y no en
una tabla.
  

1.4.7      SELECTS A VARIAS TABLAS – JERARQUÍA DE

RENDIMIENTO
De mejor a peor:

AAAA Inner joins > Select + For all entries > > Selects anidados

Cuando se require accede al contenido de varias tablas relacionadas hay

varias formas de hacerlo y el rendimiento es muy diferente aunque el
resultado sea el mismo.

1. A) INNER JOINS
SELECT * INTO CORRESPONDING FIELDS OF TABLE
li_datos

FROM EKKO

INNER JOIN EKPO ON ekko~ebelnr = ekpo~ebeln

WHERE ekpo~matnr = pi_matnr

…
La unión de las tablas se realiza directamente en la base de datos, es lo más
eficiente

 
1. A) FOR ALL ENTRIES
SELECT * INTO CORRESPONDING FIELDS OF TABLE
li_datos

FROM EKKO

FOR ALL ENTRIES IN li_tabla_auxiliar

WHERE ebeln = li_tabla_auxiliar-ebeln
AND ebelp = li_tabla_auxiliar-ebelp

…
La diferencia es que mientras en el join la unión se realiza entre 2 tablas de
la base de datos, aquí se emplean los registros una tabla interna dentro de la
cláusula WHERE del SELECT. En general, puede sustituirse por un rango
y convertirse en un SELECT normal que es mucho más eficiente.

No obstante, hay un caso en el que está justificado que es cuando existe una
interdependencia entre los campos del FOR ALL ENTRIES. Por ejemplo,
si nos interesan la posición ‘10’ del pedido ‘4500000001’ y la posición 20
del pedido ‘4500000002’, no es equivalente a seleccionar todos los
registros con pedido = ‘4500000001’ o ‘4500000002’ y posición ‘10’ o
‘20’, ya que estaríamos seleccionando también la posición ‘20’ del pedido
‘4500000001’ y la posición ‘10’ del pedido ‘4500000002’.

En este caso concreto, el FOR ALL ENTRIES no puede reemplazarse por

rangos.

1.5       ARREGLAR PROBLEMAS CON EL CÓDIGO

ABAP
 

1.5.1      Eliminar entradas duplicadas

Para las tablas internas también es posible definir claves (SORTED y
HASHED) que ayudan a acceder más rápido a los registros que cumplen las
condiciones de los campos clave.
 

Las tablas standard por defecto no están ordenadas pero se pueden ordenar,
por ejemplo, como paso previo para eliminar valores duplicados.

SORT it_table BY ebeln ASCENDING ebelp DESCENDING.

Esto ordena primero por el campo ebeln (creciente) y desempata con el
campo ebelp (decreciente)

SORT it_table BY ebeln ASCENDING ebelp DESCENDING.

DELETE ADJACENT DUPLICATES FROM it_table

COMPARING ebeln
o

DELETE ADJACENT DUPLICATES FROM it_table COMPARING

ALL FIELDS

En el caso de los rangos que posteriormente se pasan al WHERE de un

SELECT como restricciones, es fundamental haber eliminado antes las
duplicidades o podemos tener dos problemas:

1) Que tarde más.

2) Que el rango sea tan grande que desborde la memoria y provoque un

DUMP. El número de entradas que admite el rango depende de la
configuración de memoria del sistema y del tipo de datos del rango.

 
 1.5.2      READ TABLE / DELETE sobre tablas no ordenadas
Si tenemos:

LOOP li_datos AT lw_datos.

     READ TABLE li_aux INTO lw_aux WITH TABLE KEY

ebeln= lw_datos-ebeln.

ENDLOOP.

Si la tabla li_aux es de tipo STANDARD y la tabla es muy grande, el bucle

será muy lento ya que estaremos recorriendo por completo ambas tablas.

Si la tabla li_aux es una tabla SORTED/HASHED ordenada por el campo

ebeln el bucle será muy rápido incluso aunque la tabla sea muy grande.

1.6       MEDIDAS DESESPERADAS

Si nada de lo anterior funciona o no es aplicable por la estructura de las
tablas o los requerimientos concretos de informes masivos demasiado
genéricos, tenemos principalmente 2 opciones:

 Modificar las tablas creando índices secundarios. (En las tablas Z no hay
problema)
 Trasladar la ejecución del programa a un job nocturno.
Con el job nocturno no conseguimos que el programa sea más rápido, pero
conseguimos que el usuario no tenga que sufrir la espera. Por la mañana
puede obtener la información del programa en el log del job (en el caso de
los listados ALV). Programas que requieren mucha interacción con el
usuario no son susceptibles de ser transformados en Jobs.

El job nocturno tiene las ventajas de que no tiene un tiempo máximo de

ejecución y de que se ejecuta por la noche cuando la carga del sistema es
baja, evitando provocar una caída del servidor.
 

1.7       INFLUENCIA DEL ENTORNO

Cabe destacar que el desarrollo se realiza en DES, se prueba en TST y se
usa en PRD. Pueden existir diferencias en el hardware de los servidores de
cada uno de los entornos (generalmente el de productivo suele ser más
potente).

El factor más determinante sin duda es el tamaño de las tablas, en

productivo siempre van a existir muchos más datos que en DES, por lo que
lo habitual es que la transacción que no da problemas de rendimiento en
DES es lenta o incluso casi imposible de ejecutar en PRD. De ahí la
importancia de la notación-O y de que los programas sean escalables.

1.8       ARCHIVING
El archiving es un proceso de archivado que consiste en borrar de las tablas
la información antigua. Cuando se archiva, se conserva solo la cabecera de
los documentos y el contenido se saca de las tablas para que no ralenticen
las búsquedas. Normalmente, no se borrar sino que se almacena en
dispositivos externos al servidor (discos duros/cintas) donde la información
es accesible en caso de necesidad pero el proceso para recuperar la
información no es cómodo.

Las actividades de archiving se acceden desde la transacción SARA y es un

proceso muy delicado por las consecuencias potenciales en caso de hacerlo
mal.

Es muy importante tener en cuenta los requerimientos legales (no se pueden

archivar documentos financieros más recientes que 5 años en España) así
como las directrices corporativas sobre la permanencia de la información.

1.9       RECAPITULANDO
 No conviene obsesionarse con optimizar todo, nos centramos en lo que
provoca las mayores caídas de rendimiento. Usamos la transacción SAT
para diagnosticar el problema.
 

 Los problemas se concentran en los SELECTS y en los bucles anidados y la

respuesta son casi siempre, los índices, y las tablas SORTED/HASHED
respectivamente.
 

 Tiempos de respuesta inferiores a 0,2 segundos son imperceptibles. Varios

segundos son razonables para transacciones normales. Hasta varios minutos
pueden llegar a ser razonables en transacciones masivas muy pesadas o que
llaman a BAPIs que sean muy lentas. 2 horas no es un tiempo razonable,
más de un par de minutos molestan mucho. Como referencia una copia
completa de todo el servidor de SAP dura unas 3 horas.
 

 Si por los índices no hay forma de lograr un rendimiento razonable,

pensamos en crear índices secundarios o en ejecutar el programa en un job
nocturno.