Re: How many routers and message processors are us...

noctislc1

Good morning,

I need to know how many message processors and routers is apigee-x using. I saw this old thread (https://www.googlecloudcommunity.com/gc/Apigee/How-many-routers-and-message-processors-are-used-by-d...) but it's only about apigee edge. Now, the management REST API doesn't give this piece of information any more.

How can we get this information from Apigee X? We are using cloud instances.

Thank you

dchiesa1

> I need to know how many message processors and routers is apigee-x using.

Google doesn't publish that information .

why do you need to know that? Apigee X is a cloud service. Google manages it for you. Why do you need to know how Google has implemented that service?

noctislc1

Hello

We set a spike arrest policy to be triggered if we receive 200 requests per minute. However, we see it triggered already when we receive 30 request per minute. We suspect the limit is not properly calculated due to the message processors, but we don't know for sure. That's why we wanted that information, given that apigee edge gave that via REST endpoint.

This is our spike arrest policy:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<SpikeArrest async="false" continueOnError="true" enabled="true" name="SA-Threshold">
  <DisplayName>SA-Threshold</DisplayName>
  <Properties/>
  <Identifier ref="spikeArrestIdentifier"/>
  <MessageWeight ref="1"/>
  <Rate ref="spikeArrestRate">100000pm</Rate>
  <UseEffectiveCount>true</UseEffectiveCount>
</SpikeArrest>

thank you!

dchiesa1

ok I don't think I can help you with the number of processes or servers. I can't answer that. The number varies depending on load and scale. So it's sort of unanswerable, except in a particular moment the Apigee operations team would know those numbers. But your Api proxy will not know it, will not be able to access that information.

But your problem is not really "I need to know how many Message processors there are" but rather "Why is my SpikeArrest not behaving the way I think it should behave?"

And that is worth a different sort of exploration.

First let's have a look at your policy. I see you are using

<Rate ref="spikeArrestRate">100000pm</Rate>

You said you are using 200pm, but that hard-coded number there is 100k per minute. So I guess that means the variable spikeArrestRate is being set prior to the execution of this policy, is that right?

ok. Also, there is this

<MessageWeight ref="1"/>

The ref should refer to a variable name. "1" is probably not the variable name. Use that when you want the message weight to vary , depending on the request. If you want the message weight to always be fixed at 1, then... omit the MessageWeight element. I just looked at the documentation and for some reason it does not state that. I'll get that fixed.

Finally you have a "continueOnError=true" . Did you mean to do that?

ok.

Aside from all that stuff, can you give me some additional details on the values of spikeArrestIdentifier and spikeArrestRate?

Are those things _changing_ when you observe the limit of 30pm? I mean are you sending in a variety of calls, that result in different values for those variables, when you see that the result is 30pm when you expect 200pm ?

There is a bug, I think still outstanding, with some of the SpikeArrest behavior, and it may be related to the thing you are observing. Our internal references on this is b/397519452 . But without more information from you I can't say whether that is causing what you are seeing. One sure what to avoid this bug is to use a hard-coded Rate. Eg <Rate>200pm</Rate>

let me know if you have more details.

How many routers and message processors are used by default in apigee public cloud? (APIGEE-X)