Consideraciones de diseño y rendimiento para IBM i aplicaciones

Consideraciones sobre el diseño de aplicaciones

Un diseño deficiente puede afectar al rendimiento de diversas maneras. Estos problemas pueden ser difíciles de detectar porque puede parecer que el programa tiene buen rendimiento, pero puede afectar al rendimiento de otras tareas. En las siguientes secciones se explican varios problemas específicos de los programas que realizan IBM® MQ for IBM i llamadas.

Para obtener más información sobre el diseño de aplicaciones, consulte Consideraciones de diseño para aplicaciones de IBM MQ.

Efecto de la longitud del mensaje

Aunque IBM MQ for IBM i permite que los mensajes contengan hasta 100 MB de datos, la cantidad de datos en un mensaje afecta al rendimiento de la aplicación que procesa el mensaje. Para obtener el máximo rendimiento de una aplicación, envíe solamente los datos esenciales en un mensaje; por ejemplo, en una petición de cargar en una cuenta bancaria, la única información que podría ser preciso pasar del cliente a la aplicación de servidor es el número de cuenta y el importe del cargo.

Efecto de la persistencia de los mensajes

Los mensajes persistentes se registran por diario. El registro por diario de los mensajes penaliza el rendimiento de la aplicación, por lo que solamente hay que utilizar mensajes permanentes para los datos esenciales. Si los datos de un mensaje se pueden descartar cuando el gestor de colas se detiene o finaliza con error, utilice un mensaje no persistente.

Búsqueda de un mensaje determinado

La llamada MQGET suele recuperar el primer mensaje de una cola. Si utiliza los identificadores de mensaje y de correlación (MsgId y CorrelId) en el descriptor de mensaje para especificar un mensaje determinado, el gestor de colas tiene que buscar en la cola hasta encontrar ese mensaje. El hecho de utilizar de esta manera la llamada MQGET penaliza el rendimiento de la aplicación.

Colas que contienen mensajes de distintas longitudes

Si los mensajes de una cola tienen longitudes diferentes, para determinar el tamaño de un mensaje, la aplicación puede utilizar la llamada MQGET con el BufferLength campo establecido en cero, de modo que, aunque la llamada falle, devuelva el tamaño de los datos del mensaje. La aplicación puede repetir a continuación la llamada, especificando el identificador del mensaje que ha obtenido en la primera llamada y un búfer del tamaño correcto. Sin embargo, si hay otras aplicaciones que utilizan la misma cola, el rendimiento de la aplicación puede verse penalizado porque la segunda llamada MQGET invierte tiempo en buscar un mensaje que otra aplicación ya ha recuperado en el intervalo de tiempo transcurrido entre ambas llamadas.

Si la aplicación no puede utilizar mensajes de longitud fija, otra solución a este problema sería utilizar la llamada MQINQ para buscar el tamaño máximo de mensaje que la cola puede aceptar y utilizar dicho valor en la llamada MQGET. El tamaño máximo de los mensajes de una cola se almacena en el atributo MaxMsgLen de la cola. Sin embargo, este método puede consumir grandes cantidades de almacenamiento, ya que el valor de este atributo de cola puede ser el máximo permitido por IBM MQ for IBM i, que puede ser superior a 2 GB.

Frecuencia de los puntos de sincronización

Los programas que emiten numerosas llamadas MQPUT dentro de un punto de sincronización, sin comprometerlos, pueden provocar problemas de rendimiento. Las colas afectadas pueden llenarse de mensajes que no se pueden utilizar en ese momento, mientras otras tareas pueden estar a la espera de obtener esos mensajes. Este problema repercute en el almacenamiento y en las hebras asociadas a tareas que intentan obtener mensajes.

Utilización de la llamada MQPUT1

La llamada MQPUT1 solo se debe usar si hay un único mensaje que transferir a una cola. Si desea transferir más de un mensaje, utilice la llamada MQOPEN seguida de una serie de llamadas MQPUT y de una sola llamada MQCLOSE.

Número de hebras usadas

Una aplicación puede necesitar muchas hebras. A cada proceso de gestor de colas se le asigna un número máximo de hebras permitidas. Si algunas aplicaciones son problemáticas, podría deberse a que, por diseño, usan demasiadas hebras. Vea si la aplicación tiene en cuenta esta posibilidad y si toma medidas para poner freno a este tipo de problema o informar sobre él. El número máximo de subprocesos que IBM i permite es 4095. No obstante, el valor predeterminado es 64. IBM MQ pone a disposición de sus procesos hasta 63 subprocesos.

Problemas específicos de rendimiento

Problemas de almacenamiento

Si recibe el mensaje del sistemaCPF0907. Serious storage condition may existEs posible que esté llenando el espacio asociado a los IBM MQ for IBM i gestores de colas.

¿Tu aplicación funciona IBM MQ for IBM i con lentitud?

Si su aplicación ejecuta con lentitud, podría ser síntoma de que ha entrado en bucle o está esperando un recurso que no está disponible. Esta ejecución lenta también puede deberse a un problema de rendimiento. Puede que el sistema esté funcionando al límite de su capacidad. Es probable que este tipo de problema se agrave en las horas punta de carga del sistema, que suelen ser a media mañana y a media tarde. (Si la red abarca más de un huso horario, podría parecer que el pico de carga del sistema se produce a otras horas del día).

Si averigua que la degradación del rendimiento no depende de la carga del sistema, sino que a veces se produce cuando la carga del sistema es mínima, la causa puede residir en una aplicación mal diseñada. Esto puede manifestarse como un problema que solo se produce al acceder a determinadas colas.

QTOTJOB y QADLTOTJ son valores del sistema que merece la pena investigar.

Los siguientes síntomas pueden indicar que IBM MQ for IBM i funciona con lentitud:

• El sistema tarda en responder a los comandos MQSC.
• Si repetidas visualizaciones de la profundidad de la cola indican que la cola se está procesando lentamente para una aplicación con la que sería de esperar una gran cantidad de actividad de cola.
• ¿Está funcionando IBM MQ Trace?