Why Spike arrest with Rate 100pm rejects 1 request per second

Hello Experts,

We have the following definition for spike arrest policy

<SpikeArrest async="true" continueOnError="false" enabled="true" xmlns="http://www.sap.com/apimgmt">
	<!-- can be used to uniquely identify an application or a client -->
	<Identifier ref="request.header.some-header-name"/>
	<!-- used to modify the impact of a single request on the calculation of spike arrest limit. If the weight is 5 and the spike limit is 10 per minute then only 2 requests are permitted to this proxy in one minute -->
	<MessageWeight ref="request.header.weight"/>
	<Rate>100pm</Rate>
	<UseEffectiveCount>true</UseEffectiveCount>
</SpikeArrest>

Based on the thread https://discuss.google.dev/t/spike-arrest-policy-behavior-issue/248810/3, the understanding is that the policy allows 1 request per 0.6 seconds.
While most of the alerts we observe are when more than 2 requests are received in 1 second, there is an instance when 1 request is also rejected with spike arrest failure. Before this instance 22 requests were received 2mins and 21 seconds prior.
Please help understand the reason behind the behaviour of this instance and confirm if the understanding of policy allowing 1 request per 0.6 seconds is correct.
Regards,
Diptee

@rabustamante requesting your advice here.

Hey @Diptee_S You are seeing the noted behavior because of your setting of the UseEffectiveCount element to true (see more here: SpikeArrest policy  |  Apigee  |  Google Cloud) which implements a sliding window rate over the previously noted smoothing algorithm

If the above is what you are looking for (ie: 1 request over 0.6 seconds), I would recommend removing the element or setting it to false - if you need stronger consistency for the underlying rate limiter I would recommend you keep it set to true

Thanks!