Hello,

I've been working on design of a set of application that fetches incoming requests (SMS messages from mobile phones), and perform certain actions depending on request content. In the past I used synchronous DCOM approach to handle such tasks. This time I decided that handling messages synchronously is conceptually wrong. Incoming message server should be released from the rest of the system and simply queue its request. I thought this would eventually improve system performance, since different components are no longer tightly connected to each other.

So our team went for Message Queue instead, in fact we decided to use Queued Components. They are very easy to manage, and our queues should be transactional which corresponds to default QC behaviour. However, first performance tests showed that QC is now the system's bottleneck - we can't really measure performance of other system parts, because QC slows down everything. The most time-consuming operation is actually placing message in the queue. On our PIII 600 MHz machine enqueuing single message takes about 90ms. We tried different workarounds, increased number of threads, but whatever we did, we don't manage to enqueue more than 10-12 message per second. Any other operation (including data registration in SQL Server database on a different machine) takes only a fraction of this time. First I thought this is something that can be greatly improved, but after reading other comments and Alan Dickman's book about MSMQ I realised that perhaps this is normal MSMQ performance and we should not expect much more.

Now I'm trying to answer the following questions:

1. If transactional MSMQ is so slow (enqueuing not more than 10-20 messages per second on a decent machine), than if the system requires quick request handling, should it use DCOM instead? I still think traditional DCOM approach is wrong in this case, because it makes the whole process synchronous, but at least it can be hundred times faster.

2. What is the best way to scale MSMQ configuration: scaling up (by adding more memory, CPUs etc.) or scaling out (by splitting queues)? Can we use workaround by registering several queues instead of one and load balancing mutliple queues, so queued requests are posted to different queues on different machines using round-robin algorithm?

3. Having looked at performance figures, I suspect that if instead of using MSMQ we simply inserted incoming requests into a SQL Server database and implemented a monitoring process that would fetch and handle them, it could give us better performance. Again, I think this is not good design, but what if such approach increases throughput by 50-100 times?

I'll appreciate any recommendations. Honestly, I am a little confused. I've always been happy with DCOM performance (and I did use COM in real distributed environment with high workload), but I thought combining DCOM with MSMQ/QC technology would make a perfect mix due to possible separation of synchronous and asynchronous calls. I also hoped this could improve system performance, because replacement of synchronous calls with asynchronous should relax the system. I read some comments that MSMQ is kind of "email for applications" and does not have to provide fast delivery protocol, but it's not apparent for me what makes it so inefficient comparing to for example database access.

Best regards

Vagif Abilov
vagifonline.no

----------------------------------------------------------------
Users Guide http://msdn.microsoft.com/workshop/essentials/mail.asp
contains important info. Save time, search the archives at
http://discuss.microsoft.com/archives/index.html .
To unsubscribe, mailto:DCOM-signoff-requestDISCUSS.MICROSOFT.COM

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]