On Fri, Oct 21, 2011 at 01:22:42PM +0200, Jan Zelený wrote:
> - ldb_transaction_commit is called for each added user
>
> (in the end it takes ~ 14.5% of CPU time)
>
> -- we also have to consider disk write time which isn't measured by
> callgrind -- here I suggest that recent Jakub's patch is extended to
> cover all
>
> schema types and all potentially large transactions
If I understand the way ldb works correctly, data is actually only written
to disk when the topmost transaction (nesting=0) is commited.
That's good. But how about the computing logic which takes those 14.5% of CPU
time? Do you suppose that it takes place only when committing the topmost
transaction?
The two operations that have been reported as slow are getgr* and
initgroups. These operations are implemented three times - for RFC2307,
RFC2307bis and IPA schemas. RFC2307bis and IPA are very similar when it
comes to the metrics. Here's the breakdown of the operations:
1) == RFC2307 ==
i) initgroups - 3 transactions
- sdap_get_initgr_user(),
sdap_add_incomplete_groups(),
sysdb_update_members()
- I think the first one should stay, the latter two can safely be
squashed into a single one, they are both called from
sdap_initgr_common_store()
ii) group processing - 1 transaction
2) == RFC2307bis/IPA ==
i) initgroups - 2 transactions
- sdap_get_initgr_user(),
sdap_initgr_rfc2307bis_done()
ii) group processing - 2 transactions
- sdap_nested_group_populate_users(),
sdap_save_groups()
- could be squashed into a single one
So the number of transactions can still be reduced, although probably
not as much as in the case we fixed in 1.5.14. There, the complexity was
linear (N writes for N groups) and became constant. In the above cases,
we just improve a constant complexity.
I don't think that's worth the effort at this moment.
I filed two tickets to track these cases:
https://fedorahosted.org/sssd/ticket/1053 (RFC2307 initgroups)
https://fedorahosted.org/sssd/ticket/1054 (RFC2307bis group processing)
Thanks
Jan