EMS Vs. MQ for a C++ application

Discussions

Performance and scalability: EMS Vs. MQ for a C++ application

  1. EMS Vs. MQ for a C++ application (3 messages)

    Hi, I need perfromance throughput for developing a c++ application in cunjunction with either Tibco EMS or Websphere MQ. I am looking forward to use XMS, a JMS equivalent for C++; in case of MQ. Can anyone please throw light on this scenario as to what would be suitable in terms of performance. Thanks in advance. -Suman
  2. Suman, I am sure sure i'll reply to your question, but if you want to make a choice between Tibco RendezVous and MQ Series (now Websphere MQ), i'd rather make the case for Tibco, unless your interoperability requirements and constraints on the bus itself in terms of fault tolerance and clustering are very strong. I don't know the specificities of the context in which you have a make a product choice, but generally speaking, Tibco in more advanced for any publish/subscribe exercise. Tibco is also easier to administer, to troubleshoot, and to get to work. MQ requires a lot of administration, often manual (queue declarations, clusters, channels, triggers and a bunch of things increasing the deployment cost exponentially on a large scale basis). With Tibco, you can create your queues and topics dynamically, configure the deamon easily to cross subnets etc. In terms of throughput, i have not done any formal testing on the same hardware, but i know Tibco is aggressively optimized. Its use of multicast is state of the art. The size of the messages is aggressively optimized as well. I'd make the case for MQSeries if you have an absolute need for high availability, fault tolerance and clustering. That's an area where IBM is well known for doing a good job. Also, it is my understanding, but i may be wrong, that the development of MQ has been outsourced to a low-wage salary country which might not a good sign of the IBM's committment behind the product... Might also influence your choice, besides the cost.
  3. Also, it is my understanding, but i may be wrong, that the development of MQ has been outsourced to a low-wage salary country which might not a good sign of the IBM's committment behind the product... Might also influence your choice, besides the cost.
    Bullocks.. May be you work for tibco dude..! Low wage salary country doesn't mean a lower quality product, infact how do u term a firms commitment to a product? You know it is the so called nerds like you who actually stuff up enterprises, with their nerdy logic like the one above;) ciao
  4. Hi Suman, You are going to see very little performance difference between Tibco and MQ. In my experience, the real performance bottleneck is usually the XML parsing ( at both ends), and if you make the structure light and very easy to parse and use very small element names, you should be fine with performance. In history, for an extremely high thruput requirement, I had seen the performance increase by more than 40% when I game up XML for fixed width string, but then I had a very simple datastructre which was very easy to parse. You have to define the thruput you are expecting and performance you are expecting. I would say that as a thumb rule, you can consider that 1 CPU can process approx 1 MB of XML Message per second. So if you are talking about < 5 KB message size and < 20 messages per second, then you are going to get a good performance while you still use the system of your choice. Other things which effect performance are whether you use the transactional nature of the queues or not. I guess you would want transactional queues to ensure you donot lose a single message, however these come at a cost. Pranshu