Maximum number of Semp V2 calls at a time?

We have 3000+ queues in a appliance. We would like get all the queues information in JSON. We have a Python application Which makes SEMP V2 GET call to get all these queue information.
Is it okay to issue concurrent SEMP v2 GET calls to the appliance ?
I believe appliance will process the API call one after the other.
We will run this application once in a week to get the queue information.
@Aaron
Tagged:
Comments
Yes, it is ok. But I would actually suggest that you strongly consider using SEMPv1 for this particular use case. As of the time of this writing, SEMPv1 performance still significantly exceeds SEMPv2, and if you're pulling back information for 3k queues, that could take some significant time in SEMPv2. (note, there are performance enhancements being made, just not sure when they are ready). SEMPv2 is great for configuration, where you have the full RESTful verbs/methods to build objects. But just fetching data, especially for a large number of queues/objects, I'd suggest (at least looking at) SEMPv1. Just means that you have to parse XML instead. But is much faster.
Send a POST with the payload:
to the broker management port with
/SEMP
as the URL path. It will return 100 elements on one "page", and then at the end of the response will give you a "more cookie" for you to get the next page. Repeat until all done. Will be much faster than asking for 3,000 individual queues via SEMPv2.I should also probably answer the question asked though too... I believe the broker can have up to 500 simultaneous SEMP calls against it, but the recommendation from Solace is to limit to 10 calls per second. So you shouldn't ask for each queue individually, but in batches (similar to my SEMPv1 advice above).
@Aaron Is there any similar call in SEMP v1 to get all subscriptions from all the queues? It is possible in cli, which gives all the information in one call.
Hey @Manikanta sorry for the delay. Ok, let's respond to your questions:
<detail/>
with<subscriptions/>
no paging
to turn off paging, and then doshow queue * subs
to dump out all queue and subscription details to the console. Can then cut-and-paste that into notepad or something.Hope that helps!
I guess, to be crystal clear, if you wanted to use SEMPv1, you could (as an example, using
curl
):NOTE 1: if appliance, you'll be using port 80 on the management plane, and not 8080
NOTE 2: don't use admin credentials for monitoring!!!! Create a read-only user specifically for monitoring.
NOTE 3: if you have more than 100 queues, you'll have a "more-cookie" at the end of the response... that is what you ask back to the appliance to get the next batch of results.