Project

General

Profile

Actions

Task #290

closed

Synchronization - profiling

Added by Vít Švanda over 7 years ago. Updated over 7 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Vít Švanda
Category:
Synchronization
Target version:
Start date:
01/26/2017
Due date:
% Done:

100%

Estimated time:
Owner:
Actions #1

Updated by Vít Švanda over 7 years ago

  • % Done changed from 0 to 30

Result for 1000 accounts in table (used table connector).

- Reconciliace (Provisioning ON, Workflow not used)
-- 2000s (1 account / 2s).
- Reconciliace (Provisioning OFF, Workflow not used)
-- 620s (1 account / 0,6s).
- Reconciliace (All situations on IGNORE)
-- 140s (1 account / 0,14s).
- Reconciliace (Provisioning ON, Workflow start for all situations)
-- 4500s (1 account / 4.5s).
- Reconciliace (Provisioning OFF, Workflow start for all situations)
-- 800s (1 account / 0.8s).

I found problem with linear growing time for resolving one account.
- For example .. first 100 accounts are resolved per 0,5s but after resolved 1000 account is time for one account 2s.
- I have not found solution yet.
- Next I try do synchronization for 10000 accounts.

Actions #2

Updated by Vít Švanda over 7 years ago

This problem is very important and big.
- I let synchronization run all night and after 10 hours was for resolve 1 account need 60s!
- Problem is not in transactions (I am off them).
- Problem is not in search accounts on target system (I loaded 15 000 accounts in 10s).
- Problem is not in provisioning (I am off him).
- Problem is not in database. After operation end and start again is speed OK (1 account per 1s for first cca 200, then speed slowing down). I try do reindex all DB table ... without effect on problem.

Actions #3

Updated by Vít Švanda over 7 years ago

I searched for other possible causes. Still without success.
- Problem is not in tomcat settings (I try set ReservedCodeCacheSize and many others).
- I totally remove log persists during synchronization (without effect).
- Problem is not in Groovy sandbox (I am off him).
- Problem is not in database ... I try application under H2 DB, with same problem.

Actions #4

Updated by Vít Švanda over 7 years ago

Hooray, finally, incredible .... I probably found couse and solution !!!!!!

Problem is in combination of Transaction, log persist and Hibernate cache (flush, evic, clear).

Actions #5

Updated by Vít Švanda over 7 years ago

  • Status changed from New to In Progress
  • % Done changed from 30 to 90
Actions #6

Updated by Vít Švanda over 7 years ago

  • Status changed from In Progress to Closed
  • % Done changed from 90 to 100

Results after optimalization:

- Create 50 000 identities (used WF and provisioning for every item) per cca 2 hours (8 items per 1s).
- Update 50 000 identities per 4 hours (4 items per 1s).

Actions

Also available in: Atom PDF