Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
# Prácticas recomendadas de Amazon MQ para ActiveMQ
Utilice esta sección como referencia para encontrar rápidamente recomendaciones que le permitan maximizar el rendimiento y minimizar los costos al usar agentes de ActiveMQ en Amazon MQ.
## No modifique ni elimine nunca la interfaz de red elástica de Amazon MQ
Cuando se [crea un agente de Amazon MQ](getting-started-activemq.md) por primera vez, Amazon MQ aprovisiona una [interfaz de red elástica](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_ElasticNetworkInterfaces.html) en la [nube virtual privada (VPC)](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Introduction.html) de la cuenta y, por lo tanto, requiere una serie de [permisos de EC2](security-api-authentication-authorization.md). La interfaz de red permite al cliente (productor o consumidor) comunicarse con el agente de Amazon MQ. Se considera que la interfaz de red está dentro del *ámbito del servicio* de Amazon MQ, a pesar de que forma parte de la VPC de la cuenta.
**aviso**
No se debe modificar ni eliminar esta interfaz de red. Si se modifica o elimina la interfaz de red, se puede provocar una pérdida permanente de la conexión entre la VPC y el agente.
## Usar siempre el grupo de conexiones
En un escenario con un único productor y un único consumidor (como el tutorial [Introducción: Creación y conexión con un agente de ActiveMQ](getting-started-activemq.md)), puede usar una sola clase [http://activemq.apache.org/maven/apidocs/org/apache/activemq/ActiveMQConnectionFactory.html](http://activemq.apache.org/maven/apidocs/org/apache/activemq/ActiveMQConnectionFactory.html) para cada productor y consumidor. Por ejemplo:
```
// Create a connection factory.
final ActiveMQConnectionFactory connectionFactory = new ActiveMQConnectionFactory(wireLevelEndpoint);
// Pass the sign-in credentials.
connectionFactory.setUserName(activeMqUsername);
connectionFactory.setPassword(activeMqPassword);
// Establish a connection for the consumer.
final Connection consumerConnection = connectionFactory.createConnection();
consumerConnection.start();
```
Sin embargo, en escenarios más realistas con varios productores y consumidores, puede resultar costoso e ineficiente crear un gran número de conexiones para varios productores. En estos escenarios, debe agrupar varias solicitudes de productor mediante la clase [http://activemq.apache.org/maven/apidocs/org/apache/activemq/jms/pool/PooledConnectionFactory.html](http://activemq.apache.org/maven/apidocs/org/apache/activemq/jms/pool/PooledConnectionFactory.html). Por ejemplo:
**nota**
Los consumidores de mensajes *nunca* usan la clase `PooledConnectionFactory`.
```
// Create a connection factory.
final ActiveMQConnectionFactory connectionFactory = new ActiveMQConnectionFactory(wireLevelEndpoint);
// Pass the sign-in credentials.
connectionFactory.setUserName(activeMqUsername);
connectionFactory.setPassword(activeMqPassword);
// Create a pooled connection factory.
final PooledConnectionFactory pooledConnectionFactory = new PooledConnectionFactory();
pooledConnectionFactory.setConnectionFactory(connectionFactory);
pooledConnectionFactory.setMaxConnections(10);
// Establish a connection for the producer.
final Connection producerConnection = pooledConnectionFactory.createConnection();
producerConnection.start();
```
## Usar siempre el transporte de conmutación por error para conectarse a puntos de enlace de varios agentes
Si necesita que su aplicación se conecte a puntos de enlace de varios clientes, por ejemplo, cuando usa un modo de implementación [activo/de reserva](amazon-mq-broker-architecture.md#active-standby-broker-deployment) o cuando [migra desde un agente de mensajes local a Amazon MQ](https://docs.aws.amazon.com//amazon-mq/latest/migration-guide/), utilice el [transporte de conmutación por error](http://activemq.apache.org/failover-transport-reference.html) para permitir que sus consumidores se conecten con uno de ellos de forma aleatoria. Por ejemplo:
```
failover:(ssl://b-1234a5b6-78cd-901e-2fgh-3i45j6k178l9-1.mq.us-east-2.amazonaws.com:61617,ssl://b-9876l5k4-32ji-109h-8gfe-7d65c4b132a1-2.mq.us-west-2.amazonaws.com:61617)?randomize=true
```
**importante**
Los agentes de zonas de disponibilidad múltiple pueden experimentar conmutaciones por error durante los periodos de mantenimiento y los reinicios del agente. Utilice el transporte de conmutación por error para garantizar la disponibilidad de su agente.
## Evitar usar los selectores de mensajes
Es posible usar [selectores JMS](https://docs.oracle.com/cd/E19798-01/821-1841/bncer/index.html) para asociar filtros a suscripciones a temas (para dirigir los mensajes a los consumidores en función de su contenido). Sin embargo, el uso de selectores JMS llena el búfer de filtro del agente de Amazon MQ, impidiéndole filtrar mensajes.
En general, no permita a los consumidores dirigir los mensajes, ya que, para que el desacoplamiento de consumidores y productores sea óptimo, tanto el consumidor como el productor deben ser efímeros.
## Preferir los destinos virtuales a las suscripciones duraderas
Una [suscripción duradera](http://activemq.apache.org/how-do-durable-queues-and-topics-work.html) puede ayudar a garantizar que el consumidor reciba todos los mensajes publicados en un tema, por ejemplo, tras la restauración de una conexión perdida. Sin embargo, el uso de las suscripciones duraderas también impide el uso de la competencia de consumidores y puede tener problemas de desempeño a escala. Considere la posibilidad de utilizar [destinos virtuales](http://activemq.apache.org/virtual-destinations.html) en su lugar.
## Si utiliza el emparejamiento de Amazon VPC, evite el cliente IPs en el rango CIDR `10.0.0.0/16`
Si está configurando el emparejamiento de Amazon VPC entre la infraestructura local y su agente de Amazon MQ, no debe configurar las conexiones de los clientes dentro del rango de CIDR. IPs `10.0.0.0/16`
## Desactivar el almacenamiento y el envío simultáneos en colas con consumidores lentos
De forma predeterminada, Amazon MQ optimiza las colas para los consumidores rápidos:
+ Se considera que los consumidores son *rápidos* si pueden mantener el ritmo de los mensajes generados por los productores.
+ Se considera que los consumidores son *lentos* si una cola crea un atasco de mensajes sin confirmar, lo que puede provocar una reducción en el rendimiento del productor.
Para indicar a Amazon MQ que optimice las colas para los consumidores lentos, establezca el atributo `concurrentStoreAndDispatchQueues` en `false`. Para ver una configuración de ejemplo, consulte [`concurrentStoreAndDispatchQueues`](child-element-details.md#concurrentStoreAndDispatchQueues).
## Elegir el tipo de instancia de agente correcto para obtener el mejor desempeño
La velocidad de los mensajes de un [tipo de instancia de agente](broker-instance-types.md) depende del caso de uso de su aplicación y de los siguientes factores:
+ Uso de ActiveMQ en modo persistente
+ Tamaño del mensaje
+ El número de productores y consumidores
+ El número de destinos
### Descripción de la relación entre el tamaño del mensaje, la latencia y el rendimiento
Dependiendo de su caso de uso, es posible que un tipo de instancia de agente más grande no mejore necesariamente el desempeño del sistema. Cuando ActiveMQ escribe mensajes en un almacenamiento duradero, el tamaño de sus mensajes determina el factor limitante de su sistema:
+ Si sus mensajes son más pequeños que 100 KB, la latencia de almacenamiento persistente es el factor limitante.
+ Si sus mensajes son más grandes que 100 KB, el desempeño de almacenamiento persistente es el factor limitante.
Cuando se utiliza ActiveMQ en modo persistente, la escritura en el almacenamiento se produce normalmente cuando hay pocos consumidores o cuando los consumidores son lentos. En el modo no persistente, la escritura en el almacenamiento también se produce con consumidores lentos si la memoria del montón de la instancia del agente está llena.
Para determinar el mejor tipo de instancia de agente para su aplicación, recomendamos probar diferentes tipos de instancia de agente. Para obtener más información, consulte [Amazon MQ para tipos de instancia de agentes de ActiveMQ](broker-instance-types.md) y también [Medición del rendimiento para Amazon MQ mediante el punto de referencia de JMS](https://aws.amazon.com/blogs/compute/measuring-the-throughput-for-amazon-mq-using-the-jms-benchmark/).
### Casos de uso para tipos de instancias de agentes más grandes
Hay tres casos de uso comunes cuando los tipos de instancia de agente más grandes mejoran el desempeño:
+ **Non-persistent mode** (Modo no persistente): cuando la aplicación sea menos sensible a la pérdida de mensajes durante la[ conmutación por error de la instancia del agente](amazon-mq-broker-architecture.md#active-standby-broker-deployment) (por ejemplo, cuando se emiten resultados deportivos), a menudo es posible utilizar el modo no persistente de ActiveMQ. En este modo, ActiveMQ escribe mensajes en el almacenamiento persistente solo si la memoria acumulada de la instancia del agente está llena. Los sistemas que utilizan el modo no persistente pueden beneficiarse de una mayor cantidad de memoria, una CPU más rápida y una red más rápida disponibles en tipos de instancia de agente más grandes.
+ **Fast consumers** (Consumidores rápidos): cuando hay consumidores activos disponibles y el indicador [`concurrentStoreAndDispatchQueues`](child-element-details.md#concurrentStoreAndDispatchQueues) está habilitado, ActiveMQ permite que los mensajes fluyan directamente del productor al consumidor sin enviar mensajes al almacenamiento (incluso en modo persistente). Si su aplicación puede consumir mensajes rápidamente (o si puede diseñar sus consumidores para que lo hagan), puede beneficiarse de un tipo de instancia de agente más grande. Para permitir que la aplicación consuma mensajes más rápidamente, añada subprocesos de consumo a las instancias de aplicación o escálelas vertical u horizontalmente.
+ **Batched transactions** (Transacciones por lote): cuando se utiliza el modo persistente y se envían múltiples mensajes por transacción, se puede obtener un mayor rendimiento general de los mensajes utilizando tipos de instancia de agente más grandes. Para obtener más información, consulte la sección sobre la [necesidad de usar transacciones](http://activemq.apache.org/should-i-use-transactions.html) en la documentación de ActiveMQ.
## Elegir el tipo de almacenamiento de agente correcto para obtener el mejor rendimiento
Para aprovechar el alto nivel de durabilidad y la replicación en varias zonas de disponibilidad, utilice Amazon EFS. Para aprovechar la baja latencia y el alto rendimiento, utilice Amazon EBS. Para obtener más información, consulte [Tipos de almacenamiento de Amazon MQ para ActiveMQ](broker-storage.md).
## Configurar la red de agentes correctamente
Al crear una [red de agentes](network-of-brokers.md), configúrela correctamente para su aplicación:
+ **Enable persistent mode** (Habilitar modo persistente): dado que cada instancia de agente (en relación con sus pares) actúa como un productor o un consumidor, las redes de agentes no proporcionan replicación distribuida de mensajes. El primer agente que actúa como consumidor recibe un mensaje y lo mantiene en almacenamiento. Este agente envía una confirmación al productor y reenvía el mensaje al siguiente agente. Cuando el segundo agente confirma la persistencia del mensaje, el primer agente elimina el mensaje.
Si se deshabilita el modo persistente, el primer agente confirma al productor sin mantener el mensaje en almacenamiento. Para obtener más información, consulte [Replicated Message Store](http://activemq.apache.org/replicated-message-store.html) y [What is the difference between persistent and non-persistent delivery?](http://activemq.apache.org/what-is-the-difference-between-persistent-and-non-persistent-delivery.html) en la documentación de Apache ActiveMQ.
+ **Don't disable advisory messages for broker instances** (No desactivar mensajes de aviso para instancias del agente): para obtener más información, consulte [Mensaje de aviso](http://activemq.apache.org/advisory-message.html) en la documentación de Apache ActiveMQ.
+ **Don't use multicast broker discovery** (No utilice detección del agentes mediante multidifusión): Amazon MQ no admite la detección de agentes mediante multidifusión. Para obtener más información, consulte [What is the difference between discovery, multicast, and zeroconf?](http://activemq.apache.org/multicast-transport-reference.html) en la documentación de Apache ActiveMQ.
## Para evitar los reinicios lentos, recupere las transacciones XA preparadas
ActiveMQ admite transacciones distribuidas (XA). Saber cómo procesa ActiveMQ las transacciones XA puede ayudarle a evitar tiempos de recuperación lentos cuando se reinicia el agente y conmutaciones por error en Amazon MQ.
Las transacciones XA preparadas sin resolver se repiten en cada reinicio. Si estas permanecen sin resolver, su número irá creciendo con el tiempo, lo que aumentará considerablemente el tiempo necesario para iniciar el agente. Esto afecta al tiempo de reinicio y de conmutación por error. Debe resolver estas transacciones con una instrucción `commit()` o `rollback()` para que el rendimiento no se degrade con el paso del tiempo.
Para supervisar las transacciones de XA preparadas no resueltas, puede utilizar la `JournalFilesForFastRecovery` métrica de Amazon CloudWatch Logs. Si este número aumenta o es sistemáticamente mayor que `1`, debería recuperar sus transacciones sin resolver con código similar al que se incluye en el siguiente ejemplo. Para obtener más información, consulte [Cuotas en Amazon MQ](amazon-mq-limits.md).
El siguiente código de ejemplo recorre las transacciones XA preparadas y las cierra con un `rollback()`.
```
import org.apache.activemq.ActiveMQXAConnectionFactory;
import javax.jms.XAConnection;
import javax.jms.XASession;
import javax.transaction.xa.XAResource;
import javax.transaction.xa.Xid;
public class RecoverXaTransactions {
private static final ActiveMQXAConnectionFactory ACTIVE_MQ_CONNECTION_FACTORY;
final static String WIRE_LEVEL_ENDPOINT =
"tcp://localhost:61616";;
static {
final String activeMqUsername = "{{MyUsername123}}";
final String activeMqPassword = "{{MyPassword456}}";
ACTIVE_MQ_CONNECTION_FACTORY = new ActiveMQXAConnectionFactory(activeMqUsername, activeMqPassword, WIRE_LEVEL_ENDPOINT);
ACTIVE_MQ_CONNECTION_FACTORY.setUserName(activeMqUsername);
ACTIVE_MQ_CONNECTION_FACTORY.setPassword(activeMqPassword);
}
public static void main(String[] args) {
try {
final XAConnection connection = ACTIVE_MQ_CONNECTION_FACTORY.createXAConnection();
XASession xaSession = connection.createXASession();
XAResource xaRes = xaSession.getXAResource();
for (Xid id : xaRes.recover(XAResource.TMENDRSCAN)) {
xaRes.rollback(id);
}
connection.close();
} catch (Exception e) {
}
}
}
```
En un escenario real, puede comparar sus transacciones XA preparadas con las del administrador de transacciones XA. A continuación, puede decidir si tratar cada transacción preparada con una instrucción `rollback()` o `commit()`.