Layer7 API Management

While sending the data from A to B it is going through Layer 7, A want to send to Layer 7 over JMS and Layer 7 will send to B over http.Since A don’t want to wait for the session and hold the thread to process next message, It is planned to fire and forget about that message and relying on Layer 7 to handle buffer and throttle.B can say that they can handle 6K per minute and later they can say 5K or 4K per minute. Whereas A will just publish all the records to Layer 7 over JMS.

Hello,

Just to clarify,

you want to throttle or shape load, depending on backend behavior, but the threshold is a dynamic value, which is determined by the backend?

1. How does the backend plan to let us know what that value is?

We have a few assertions ( Apply Rate Limit and Apply Throughput Quota ), that can be used to throttle traffic, depending on specifics.

Both can take a Context variable in regards to what the threshold could be.

The fancy part here is determining how that context variable gets updated, on what basis invokes an update, etc. etc.

2. Can the backend Populate a Custom HTTP header? ( I'm assuming this is too much logic on the backend and the answer is 'NO' )

Another idea that comes to mind is having predefined thresholds, ( You should have a good idea what your thresholds are ), and in you Policy Logic, you would (throttle/shape) based on another value, maybe time of day or some prepopulated variable somewhere?

Chapter 9 of the 'Layer 7 Policy Authoring User Manual.pdf' starts off will these two assertions for your reference.( It has some nice specifics on how to use the assertion and what context variables it uses and is populated)

Remember, Throttling will fail requests if the threshold is breached and Shape will queue the thread. (be careful with shape, as if your threshold is too low, and your queue depth is too high, you can run up your thread usage as well as memory)

Reply back with what you are planning and we should be able to guide you in the right direction.

hope this helps,

Doyle

Thanks Doyle,

That helps..

between point 1, this could be timing (like some specific timing of a day) or a manual support call to inform that backend is ready to take up more load and they yes backend is not sending any custom http header:)

Let us try to use those assertion in right manner along with shared and clustered flag and will see what up to what extent we can achieve this.

Thanks again.

Ashish

The Easy way would be to put the Threshold value in a Clusterwide Property(i.e. 100 tps) and have your rate limit/throughput quota assertion reference that value to throttle/shape on. If your support team gets a call to up or lower the value, all they have to do is modify the clusterwide property value. They can do this via Policy Manager or Depending on the Gateway version, we have a programmatic approach to accomplish this update as well. You can combine this with any branching logic in your policy as well, to make sure you throttle/shape only when you need to.

Will this require a new deployment in production since that is what we don't want.

If by deployment, you mean Policy Modification and Additional Clusterwide property, Yes, these will need to be set up in Production.

I don't see an approach where a Policy modification wouldn't be necessary here, if you want the Gateway to Handle the throttling...

sorry, I meant deployment at each and every time when we get call from backend once they ready to change the rate limit, or its just one time change and then will work as per the clusterwide property.

The way I would approach this would be to get an idea of what that specific backend can handle. Maybe via load testing the backend directly and come up with a good number that is backed up by Performance Testing Data. Assuming the gateway is the only client to that server, we have a good idea of what load we can send. Lets say the backend maxed out at 220 tps before it choked. Also, lets assume you have a 2 node Gateway cluster. We can set the Clusterwide value to 100 ( 100 tps per node will give us about 200 tps total ), which is slightly under the backends max load, b/c we don't check throughput in real time, I believe there is an 8 second delay, which is configurable.

With this approach, I don't see you having to modify that value much, unless there is other things going on on the backend, other than Gateway traffic, if it is truly unstable, I would lower our clusterwide property value to a more safe number, to account for any inconsistencies that may be happening back there. If they are constantly wanting that value to be modified, you may want to focus on 'the why' here..

If you must, SSG V8.2.x and up, exposes our RESTMAN API, which I believe gives us access to modify values via an API call?...( Not sure if you consider this a deployment or not )