Traffic jams (part II)

by Deborah Volk on March 20th, 2009

Read Traffic Jams (part I) to get the first part of the story

How do you mitigate the risk of a deadly spike in message volume without upgrading hardware? Using a cloud-based architecture is one way. If you've deployed OIM on a grid that could grow or shrink its computational capacity, you've got a way out. This is a realistic but bleeding-edge scenario and I am not aware of any customers that have done that. Thankfully the smart engineers at major app server vendors knew about this issue before the word grid entered IT vocabulary and introduced an intelligent solution - flow control. Flow control came from, well, pipes and valves. Here's a demonstration of a pipe and valve combination that is a very close analogy to a JMS queue with flow control. The valve dynamically shrinks or expands without bursting the pipe or requiring a different pipe. Pay close attention to this death-defying trick, this is the only identity management blog that combines the magic of industrial engineering with multimedia presentation to illustrate a point:
In the pipe and valve combination, the aperture of the valve is manually adjusted to control the flow. If a human operator finds out that the flow rate of material through the pipe needs to be reduced or increased, he goes to the valve and acts on his information. The flow control in app servers is smarter. That is, we can define a threshold of messages (max/min) in the queue. The threshold includes all message states - pending, in-flight, in-transaction, etc. If the number of messages in the queue reaches the threshold, the app server automatically adjusts the flow rate. The flow rate is adjusted to some number that you specify in the app server configuration. If the max threshold is breached, the valve opening will grow smaller down to a specified minimum flow rate (messages/sec) which will be used by producers to push messages into the queue. If the queue is emptied really fast so that the number of messages goes down to a minimium threshold, the entrance of the pipe grows larger up to a maximum rate used by producers.

With flow control turned off, producers and consumers could act as they please and the queue is infinite. Under most normal operating conditions no flow control is needed but if you experience a spike and corresponding backlog, flow control can be the difference between a chugga-chugga server and a puff-puff-out of breath server. In OIM 9.1, the flow control is on by default with thresholds set at 250 max and 20 min. If you're on an earlier version of OIM, you should investigate turning on flow control as a way of improving OIM performance.


Posted in Oracle Identity Manager    Tagged with jms, queues, performance, oim


0 Comments


Leave a Comment
Search

Subscribe

follow on

2012 (1)
2011 (2)
2010 (2)
2009 (64)
March (11)
April (18)
May (18)
June (4)
July (1)
August (1)
September (5)
October (5)
December (1)