Hi all,
We have the following NSO “performance related” conceptual doubt: We need to do re-deploy no-networking of a large set of service instances. We have two scenarios:
1) Single transaction involving a large set of service instances, for example:
(config)# services l3vpn xyz1 touch
(config)# services l3vpn xyz2 touch
(config)# services l3vpn xyz3 touch
……
(config)# commit no-networking
In this case we have a single NSO transaction that will invoke the service create() function for all the service instances inside the transaction. As far as we understand, the creates are invoked serially, one after another, and executed by the service package Python VM. Are we right in this statement? Or are the creates() executed in parallel using different threads of the Python VM?
2) Many different transactions each involving a service instance re-deploy. In this case, the service create() function is called inside each transaction, and as transactions are executed serially, one after another, the same happens with the creates(). If in this case, instead of create, we use pre_lock_create(), then the creates are executed outside the NSO transactions, and could potentially be executed in parallel, if the create() generated config change sets are not overlapping.
All these creates() are done by the service package Python VM. Are these creates() executed in parallel using different threads of the Python VM? Or are also executed serially?
And in both situations, when we talk about Python VM threads, are these threads operating system threads or Python “threading” module threads? In the case of Python threads, we understand that they are just a parallelism illusion, because of the Global Interpreter Lock (GIL), they execute serially not like native operating system threads.
Is Python a limitation in these scenarios? Could we get better performance using Java creates() instead of Python ones?
Any help, clarification, correction or suggestions welcome!!
Regards
Oscar
