[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference pamsrc::decmessageq

Title:	NAS Message Queuing Bus
Notice:	KITS/DOC, see 4.*; Entering QARs, see 9.1; Register in 10
Moderator:	PAMSRC::MARCUSEN

Created:	Wed Feb 27 1991
Last Modified:	Fri Jun 06 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	2898
Total number of notes:	12363

2778.0. "SAF writing becomes slow" by BERGIL::GUY () Wed Feb 19 1997 13:00

A customer has the following problem :

They run DMQ3.2A between a VMS system and a UNIX3.2 system


If they send messages with SAF writing and then stop group on the target (Unix)
for some time and accumulate around 960 messages in the SAF file, when they
restart the target group, the sending process running on VMS becomes very slow.

It seems that the process getting messages from the SAF file for their 
retransmission to the UNIX system, slows down considerably the normal sending
process which of course does need to store the send messages in the SAF file.

Is this behaviour normal, or in another way is there a limit for the number
of messages that can be "Buffered" in the SAF file to avoid this problem.

Any help will be greatly appreciated.

Jean-Paul.

T.R	Title	User	Personal Name	Date	Lines
2778.1	need more info	PAMSIC::POPP	Deep in the Heart...	`Thu Feb 20 1997 14:49`	17
	>Is this behaviour normal, or in another way is there a limit for the number >of messages that can be "Buffered" in the SAF file to avoid this problem. Questions... 1) Specifically what delivery mode and uma combination is the customer using? 2) When you say that the system slows down what exactly do you mean by that? How much does it slow down by? How fast was it going before the link to the Unix group was lost? Can you give an example of messages/second? 3) Any errors or other messages of interest in the EVL log file? -Lisa
2778.2	Dequeuing from SAF	GVA05::GUY		`Fri Feb 21 1997 04:51`	29
	>Questions... >1) Specifically what delivery mode and uma combination is the customer using? PDEL_MODE_WF_DQF PDEL_UMA_SAF >2) When you say that the system slows down what exactly do you mean by that? > How much does it slow down by? How fast was it going before the link to > the Unix group was lost? Can you give an example of messages/second? Actually when they do a normal transmission between VMS and UNIX, they can send up to 10 mess/second. If they stop the group on UNIX, messages are stored in the SAF file at a speed of 40 messages /second. They restart UNIX group when 960 messages have been stored in the SAF file. At this point transmission becomes very slow (1 message sent every 10 seconds) >3) Any errors or other messages of interest in the EVL log file? I have customer to provide them Jean-Paul.
2778.3		XHOST::SJZ	Rocking the Messaging Desktop !	`Fri Feb 21 1997 09:23`	22
	I am not certain about VMS, but on the other platforms we favor draining the SAF over incoming traffic. That can and does have an impact on enqueue rates when there is a large backlog of messages. In fact the non-VMS im- plementatins UNIX always favor dequeuing over enqueuing (for all delivery modes). On UNIX, there is no way to defeat this. All internal traffic is sent at an elevated priority (higher than 0 or 1). On VMS, and I am sure I will be corrected if I am wrong, I believe the internal MRS traffic flows at a priority of 1. So, if you send your messages at a priority of 1 you should be able to compete with a draining SAF (unless of course the MRS server receives internal traffic on another queue and uses a selection). But I must admit 0.1 messages per second is pretty bad, and there may be something else going on. Does the rate go back up once the SAF is drained ? _sjz.
2778.4		PAMSIC::POPP	Deep in the Heart...	`Fri Feb 21 1997 11:08`	18
	> PDEL_MODE_WF_DQF > PDEL_UMA_SAF Here's the killer. You said to wait-for DQF so as long as the link is up and message traffic is flowing the user will sit waiting until the message in enqueued into the DQF or a timeout occurs. In order to maintian FIFO, if there are SAF messages ahead of the pending WF_DQF/SAF message then this message has to get behind the rest and wait for his turn. If the user does not REALLY want to wait until the message is enqueued into the DQF then they can change their delivery mode to PDEL_MODE_WF_SAF, PDEL_UMA_DISCL. The user will be unblocked as soon as the message hits the SAF. My guess is that they probably have a timeout of 10 seconds and that is why they are seeing 1 message every 10 seconds. -Lisa