Hi Morgan,
The below information is from AT&T’s November release performance testing: [cid:[email protected]] With about 5 million nodes and running a production network call profile we see a throughput of about 27 tx/s and an average response time of 0.58 secs. This timing increases to about 0.85 secs with a load that is about 127 tx/s over a 3-4 hour test. This is not to say that is our limit, but based on the call profile it’s what the microservices achieved. I have seen 400+ tx/s in production. Our performance testing is done with a baseline run (profile of calls done in production) which is compared release to release. We then move on to stress testing which scales up the users and calls. The calls vary in timing & nature etc. ie. a 100ms patch call is different from a 5 second traversal or get all nodes call. As far as limits we always observe the cpu, memory, etc allocated to the deployment and adjust based on the results of the testing. All testing is done in gatling. In the past, AAI has responded well to hardware capacity increases (especially replicas/memory). Running scalability/endurance tests to determine limits is needed especially w.r.t the size of the graph. FYI: I am on vacation starting this afternoon until January. Any further discussion will have to be held in onap-discuss or with the other AAI committers, until I return in January. Thanks, William Reehil Principal Member of Technical Staff | A&AI ONAP PTL AT&T ECOMP PLATFORM AND SYSTEMS (C) 732 865-5333 | (O) 732 420-7806 -----Original Message----- From: [email protected] <[email protected]> Sent: Wednesday, November 24, 2021 11:01 AM To: KAJUR, HARISH V <[email protected]>; FORSYTH, JAMES <[email protected]>; REEHIL, WILLIAM E <[email protected]>; AGGARWAL, MANISHA <[email protected]>; MAHARAJH, ROBBY <[email protected]> Cc: [email protected]; [email protected]; ROUZAUT Fabian INNOV/NET <[email protected]>; SCHLEWITZ Nicolas INNOV/NET <[email protected]>; Closset, Christophe <[email protected]>; [email protected]; [email protected]; AUGIZEAU Olivier INNOV/NET <[email protected]>; [email protected]; RICHOMME Morgan INNOV/NET <[email protected]>; EDEL Nicolas INNOV/NET <[email protected]>; DESBUREAUX Sylvain INNOV/NET <[email protected]>; Lefevre, Catherine <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected]; LAMBERT Guillaume INNOV/NET <[email protected]>; [email protected]; RAJEWSKI Lukasz O-PL <[email protected]>; GUEPE Mickael INNOV/NET <[email protected]>; [email protected]; FREEMAN, BRIAN D <[email protected]>; LIARD Samuel INNOV/IT-S <[email protected]> Subject: [ONAP] [AAI] question on AAI benchmarking & dimensioning Hi AAI team, I was recently questioned on the AAI limits. Do we have any benchmark results for the AAI? Does it scale through hardware capacity upgrade or not? What would be the limitations? In our integration community stability tests dealing with instantiations, we are reasonably good with a light load (10// instantiations) during 24h but we reported errors after 30h with some exceptions including some dealing with timeouts between AAI and SO. More generally do/did the core components perform limit tests on the components? Shall we plan a stability test on AAI to figure out some limits in the future? Note AAI but also DMAAP or SDNC are indirectly tested through the stability tests in addition of SDC (onboarding) and SO (instantiation) but there is no specific processing for these components and we do not have any dimensioning figures. As AAI is used in production in Bell or AT&T, you may have some figures to share or some ideas of accurate tests to be performed and/or to be added in the list of stability tests. Thanks /Morgan _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#23664): https://lists.onap.org/g/onap-discuss/message/23664 Mute This Topic: https://lists.onap.org/mt/87283990/21656 Group Owner: [email protected] Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
