When the message is sent, you can ask for confirmation upon delivery. When the message is consumed, the report message is delivered to the response-response queue and the response to QMgr, which were set in the original message. This is relatively easy if you use the procedural interfaces of C or Java or WMQ v7.0 with any language. Report parameters are set like any other message option before PUT. http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/topic/com.ibm.mq.csqzak.doc/fr13320_.htm
In the case of JMS and WMQ v7.0, all the MQMD properties were set as JMS Message Properties, and you can set or read them. http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/topic/com.ibm.mq.csqzaw.doc/jm25500_.htm
There is another, less simple, but MUCH more detailed approach that you can consider. MA0W SupportPac ( http://www-1.ibm.com/support/docview.wss?rs=171&uid=swg24010343&loc=en_US&cs=utf-8&lang=en ) - trace output. This trace has extremely fine control, and you can enable it for one PID, for specific queues or channels, etc. This will give you API timeouts so you can see if time is being spent on API calls or calling yourself. In other words, did the program execute 10 seconds between API calls or did GET execute 10 seconds? If you return messages due to filling out the transaction log and then re-read, this can lead to delays that are pretty transparent if you don't have tracing.