IdStory Identity Manager

As first thing I did some testing.
Testing setup:

• IdM on local env, running via IDE and FE is runnig from command line
• DB is on same machine in docker
• AD system is on our company server and I am connect via VPN
• Running bulk operation of assigning role to 51 users. Account in AD is created for all of them

Scenarios:
AD without pooling
I run creation only once.
Provisioning for 51 users took 78s without synchronized methods and 70s with synchronized, but for better representation more runs will be needed.

AD with pooling
Pooling for AD was enabled then. Provisioning of 51 users is 2x times faster then without pooling.
I run each solution 10 times and the average is almost the same.
Synchronized-32,6184 sec
Non synchronized-32,2033 sec

---

IdM is currently using synchronized methods in DefaultProvisioningExecutor::execute
From testing above there is no difference, so some speed up is not that simple as remove synchronized (I expected that, but we had to start somewhere :) )

---

Next I'll look deeper into provisioning mechanism and then we will see.

Some final sum from debugging and testing

### Current situation and testing

Current implementation of provisioning for one system is parallel, but there are some part’s which are synchronized.

All tests where performed on WinRM + AD connector, which is running in connector server and has pooling enabled in IdM.

All operations are performed only via AD connector, only search operation is performed via AD and via WinRM. Thanks to that, we can easily replicate that system is slow via powershell.

Order of classes, how they are called for create

1. `IdentityRoleSaveProvisioningProcessor` - run account management
2. `DefaultProvisioningService`::`doProvisioning`
3. `ProvisioningStartProcessor`
4. `DefaultProvisioningService::doInternalProvisioning`
5. `DefaultProvisioningExecutor::execute` this is synchronized but still search run parallel(multiple searches to end system in same time not waiting till one search is finished), execution is fast
6. `DefaultProvisioningExecutor::executeInternal`
7. `PrepareConnectorObjectProcessor`
8. `ProvisioningCreateProcessor` - via connector facade perform operation to end system - multiple threads accessing this method at the same time

Thanks to logs messages, we can see that multiple searches are performed in **PrepareConnectorObjectProcessor.** So there is no limitation in IdM or connector framework in searching for multiple accounts at the same time

**ProvisioningCreateProcessor**  is accessed by multiple treads, so multiple creates are performed.

Methods in **ProvisioningCreateProcessor** are synchronized so only one thread at a time can access it, but the execution of this method is fast, so we can see that 5 searches are performed basically in the same time

Tried some testing with @async annotation and with removing synchronized, but there was no performance improvement and it causes some bugs in create operations (retry was ok, because some entities were already created).

We need to look into performance more.

The correct way how to make whole line parallel need to be find and tested. So more testing and debugging need to be done.

Things to investigate if there is some way how to improve it

- pooling
- group provisioning operations together
- make it “more” parallel

### Target state

Provisioning should be parallel all the way

We are talking about provisioning for one system = for example, provisioning for 10 users can be parallel

Provisioning for one user should be processed still in order = for example 4 operation for one user to the same system, we need to perform these operation in the correct order, because we don’t want to execute delete before create for example.