Recapitulation:
In last article we had learnt about different types of message formats i.e text stream,base64 stream,XML stream,JASON Stream.
Messaging models:
Before discussing on how to perform performance testing in messaging environment ,let discuss on messaging models . On the basis of two basic models ,n-tier messaging architecture can be built. The basic two models are Publish-and-Subscribe and Point-to-Point
Publish-and-Subscribe:
publish-and-subscribe , sometimes also called as pub/sub model is intended for a one-to-many broadcast of messages. Publishing application publishes a message on a message-store called Topic .Each subscriber /consumer applications subscribes to the topic and consumes the copy of a message ,process it further to its need.The pub/sub messaging model is a push-based model, where messages are automatically broadcast to consumers without them having to request or poll the topic for new messages.Even if any Subscriber is down, as soon as it comes back it starts getting messaging from the offset it stopped.
Point-to-Point
point-to-point is implemented for one-to-one delivery of messages.An application publisher events out messages and post it on to a queue, a subscriber process stays connected to the respective queue and polls it continuously for an incoming message. There could be multiple consumer/subscriber to a queue, but only one would receive a particular message. multiple consumers can be used to polling for filter based message payload. i.e publisher message including an attribute ranging from 1 to 100 with and also 101 to 200 and so on. for processing consumer 1 processes the messages with attribute load ranging from 1-100 and consumer 2 processes the messages with attribute load ranging from 101 to 200. but consumer 1 would not process 101 to 200 or vice versa.
Synchronous vs Asynchronous Messages:
Message processing happens through certain steps i.e. A Subscriber-> connection establishment to queue->poll message->receive message->process->repoll message. This can be done by polling for a message, complete full processing and then repoll for the new message. i.e. blocking re-polling a new message until the earlier message operation completes. this process is called synchronous .This technique resembles TCP(transmission control protocol) packets in network terminology . Synchronous process reliable but slow To resolve the slowness other techniques are taken. To resolve the slowness challenges, developers are often guided to take a certain part of the operation as non-blocking. i,e the Subscriber process pulls the message from a queue, assign it to some other module for processing, re-polls the next message from a queue, and so on. this process is called as asynchronous . This technique resembles UDP(User datagram protocol) packets in network terminology
Now that basic of very vast message-oriented middleware is understood, We need to know the “Need” to test the various attached stacks through nonfunctional aspects.
Any Business owner, Developer, Decision makers would like to know what the impact of message traffic on the infrastructure where message-oriented middleware is implemented. There could be a regular payload of messages feed in by publishing source. on the other hand, there could be an irregular situation that can occur such as “a sudden massive heavy traffic volume ” arises. This situation is very much possible in Travel, Banking, Financial organizations, Gaming domains .
Question that makes Business nervous:
- Would the consuming system scale to business need?
- what is the subscribers message processing capacity?
- whats the impact on application container?
- whats the impact on operating systems on which the overall architecture has been connected/ported
- In case consumer process has another face of being publisher to another queue would it scale the same way as compared to standalone
- whats the baseline load should be
- Is there any memory leak in the “vendor messaging “
- Is there any memory leak in the messaging implementation