Affichage des articles dont le libellé est WMQ. Afficher tous les articles
Affichage des articles dont le libellé est WMQ. Afficher tous les articles

lundi 12 novembre 2012

How to use perfharness for routes Camel & ActiveMQ


Use Performance Harness for JMS

§   This is the same tool that the WebSphere Message Broker and WebSphere MQ teams use when measuring the products.
§   Available to download on Alphaworks: http://www.alphaworks.ibm.com/tech/perfharness
§   Supports testing JMS, MQ, HTTP, SOAP
§   The tool provides:
Throttled operation (fixed rate or number of messages)
Multiple destinations
Live performance reporting
JNDI
Non JNDI for IBM JMS Providers

Running Perfharness

§   Requires Java 5 minimum
§   Set min and max heap size for the tool: -ms256M -mx256M
§   You have to put all jars of perharness in %ActiveMQ_HOME%\examples\perfharness

Example Output:

Sender1: START
rateR=3137.33,threads=1
rateR=4488.75,threads=1
rateR=4621.33,threads=1
rateR=4680.78,threads=1
rateR=4683.67,threads=1
rateR=4693.88,threads=1
rateR=4683.56,threads=1
Sender1: STOP
totalIterations=128133,avgDuration=26.53,maxrateR=4683.56
ControlThread1: STOP

The first case: Find the max rate for sending messages in a named queue and receiving messages from a named queue.

Sender.bat:

Module to measure “-tc jms.r11.Sender” sends messages to a named queue destination “-d dynamicQueues/testqueue”.
The message referenced in this batch file “Sender.bat” is persistent “-pp”, and transacted “-tx”.

java -cp "..\..\activemq-all-5.3.0-fuse-01-00.jar;./perfharness.jar" JMSPerfHarness -pc JNDI -ii org.apache.activemq.jndi.ActiveMQInitialContextFactory -iu tcp://localhost:61616?jms.useAsyncSend=true -cf ConnectionFactory -d dynamicQueues/testqueue -tc jms.r11.Sender -nt 1 -us system -pw manager -tx true -pp true

Receiver.bat:

Module to measure “-tc jms.r11.Receiver” receives messages from a named queue destination “-d dynamicQueues/testqueue”.
The message referenced in this batch file “Receiver.bat” is persistent “-pp”, and transacted “-tx”.

java -cp "..\..\activemq-all-5.3.0-fuse-01-00.jar;./perfharness.jar" JMSPerfHarness -pc JNDI -ii org.apache.activemq.jndi.ActiveMQInitialContextFactory -iu tcp://localhost:61616 -cf ConnectionFactory -d dynamicQueues/testqueue -tc jms.r11.Receiver -nt 1 -us system -pw manager -tx true -pp true

The second case: Find the max rate for my route camel.

If we consider this following route camel: the input is the queue orders and the output is the queue orderstatus.



We can find the max rate of this route camel, by sending a message in the queue “orders” and then waits for a reply on the output queue “orderstatus” with a matching CorrelationId.
The message referenced in this batch file “Req_Reply.bat” is persistent “-pp”, transacted “-tx” and contains a JMS Header “-pf”, and the Body “-mf”.
The tool will run for 120 secs “-rl” and print stats every 5 seconds “-ss”.


Req_Reply.bat

set BROKER_URL=tcp://localhost:61616?jms.useAsyncSend=true
set USER=system
set PASSWORD=manager
set QUEUE_OUT=dynamicQueues/orders
set QUEUE_IN=dynamicQueues/orderstatus
REM -nt Number of producer threads
set NT=1
java -cp "..\..\activemq-all-5.3.0-fuse-01-00.jar;./perfharness.jar" JMSPerfHarness -pc JNDI -ii org.apache.activemq.jndi.ActiveMQInitialContextFactory -iu %BROKER_URL% -cf ConnectionFactory -tc jms.r11.Requestor -iq %QUEUE_OUT% -oq %QUEUE_IN% -to 30000 -pf C:\Dev\tools\bench\InputMessages\JMSProperties.txt -mf C:\Dev\tools\bench\InputMessages\messageBody.xml -nt %NT% -ss 5 -rl 120 -pp true -tx true -us %USER% -pw %PASSWORD%


Enjoy !!

jeudi 29 décembre 2011

High Availability for WebSphere Message Broker & Websphere ESB


It’s important to consider how to ensure the performance and availability targets for a WebSphere Message Broker implementation are met. As the most common implementation of Message Broker is as a central hub that all messages in a messaging architecture are processed though, it is a potential bottleneck and single point of failure for the whole WebSphere MQ Queue Manager network.

Below the topology that I proposed and implemented in a lot of clients:



The diagram shows the topology. It consists of:

1. Two brokers BK.1 and BK.2. Each broker executes a specific set of execution groups that run each process in a specific set of flows parallelized or not.
2. Two Queue Manager WMB.BK1 and WMB.BK.2 corresponding respectively to BK.1 and BK.2 brokers.
3. A DB2 database dedicated hosting the configuration repository shared brokers.
4. The configuration manager CM to administer the two brokers.
5. The queue manager WMB.CM dedicated to configuration manager

We have also to consider the following points that contribute to high availability of any ESB environment. For example:

  • Reliable hardware
  • Shared queues
  • Heath monitoring
  • Failover clustering
  • Online backup
  • Dual networks
  • Reliable operating system
  • Online reconfiguration
  • Fast reboot
  • RAID disks
  • Crash recovery
  • Fast start up
  • IP takeover
  • Documented procedures
  • Practicing procedures