Quota Settings

[ChaitanyaVSK]

Hello,

I have q requirement of setting quota in time unit of second, from documentation i see it can be achieved by making distributed to false, but when its non distributed our setting works per MP( for example lets say i define 5 tps and i have 3 MPs it will allow 15tps)  which should not be the case it should strictly enforce 5 tps irrespective of MPs. I feel the settings defined in are contradicting , what could be the best setting we can do.

And when i say distributed = false & synchronous = true to enforce my need, quota is not applied at all its continuously allowing.

And in case when distributed true & sync= false with , async -> sync mesage count=1, not working as expected, here i did not understand how MPs are synced.

I am expecting some solution with relation between distributed, synchronous , Asynchrounous(with child attributes)

Thanks

[dknezic]

Yes, you cannot use distributed with a second timeunit on quota policy. What exactly is the use case / what are you trying to achieve with a per second quota? Would this better be solved with spike arrest policy, or expressing your quota per minute instead and then using distributed?

[ChaitanyaVSK]

HI,

The use case is to restrict the client to 5 TPS. Though we have spike we need to define quota for this requirement, if i express quota per minute it could breach 5 tps.

In Quota --> TimeUnit  Documentation i saw below note : 
Note: The policy also supports second as the time unit. However, second is only supported for non-distributed counters, as defined by Distributed=false. 

This is contradicting with another statement, Distributed: - If you use the default value of false, then you might exceed your quota because the count for each Message Processor is not shared.

But i need to maintain a central counter and continuously synchronize it across all Message Processors ( FYI 4 MPs in this usecase).

Please let me know, if you find any solution for this.

Thanks

[dknezic]

If you're using Apigee Edge, you may need to consider rolling your own solution with redis/memorystore to maintain a low latency counter. Otherwise, you could try the configuration with spike arrest on X/Hybrid.