-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I also seem to remember that Java calls that spin off new threads are
expensive. I'm not sure how this differs from regular Java calls but I
imagine it means you are decent at Java and specifically create a new
thread that does work. I could be off on this but it comes to mind.

There was a long response in this forum (I think) a few months ago on
this. Basically the meat of the response was "follow the rules you know
to make things faster and don't worry about the rest". By that the
specifics were to avoid queries to each end (we know they're slow). Do
things early in the channel that belong early in the channel and don't
depend on later operations. This prevents excessive rule processing.
Use indexes when appropriate. Don't synchronize things you don't
need/want. If I come across the post I'll reference the thread directly.

Good luck.







Father Ramon wrote:
>
> Geoffrey Carman wrote:
>> This brings up a question I passed into the Cool Solutions guys to
>> get people at Novell thinking about...
>>
>> How expensive are various operations (conditions, actions, verbs, etc)
>> in IDM?
>>
>> Or more to the point, how would one optimize an IDM rule? If you have
>> two or three approaches, which is the most efficient? I understand
>> that is way too generic, but could we try and figure some of it out?
>>
>> I was thinking that a good approach would be to start listing the
>> worst things you can do CPU/Memory/Time/Writes wise.
>>
>> So I will start off with what I think I know...
>>
>> 1) Any time you need to query something that is not in the op-doc, you
>> add time and CPU, since you need to generate a query doc, send it, get
>> it back, process it through the full rule set. So this eats time
>> mostly.
>>

>
> Queries are relatively expensive, especially if doing a search on
> something not indexed. Queries to a connected application are typically
> more expensive than queries to eDirectory. Prior to IDM 3.5, an
> important optimization would be to use token-src-attr or token-dest-attr
> to get the value of an attribute into a variable and then use the
> variable instead of repeatedly querying for the attribute in the same
> policy. In IDM 3.5 it will automatically remember it already has the
> value and use it. It will also remember previous runs of the same policy
> and query for all the attributes that the policy has used in the past
> runs when it first needs to do a query.
>
>> 2) Anything that does a lot of writes. If you need to store a
>> variable that is a nodeset, for an entire policy, you cannot use a
>> local variable until IDM 3.5. I used a placeholder object in the tree
>> to store it (alas for a biggish nodeset, dozens to hundreds of
>> nodes). This is obviously expensive as it has to write and DS is
>> single writer. So this can be a bottleneck.

>
> Writes to eDirectory are fairly expensive. Writes to the connected
> application may also be expensive. Since Policy Builder tries to
> maintain the sequential order implied by the actions in the policy, it
> is good to group changes to a single object together so that it can be
> done in a single transaction. For example if you want to do something
> that causes a modification to a related object, do it after all the
> changes to the current object rather than somewhere in the middle.
>
>>
>> But things I do not know are: Calls out to Java? Expensive? Cheap?
>> Depends on the Java class?
>>

>
> The actually call to Java is cheap. The Java that is being called may or
> may not be.
>
>> Which verbs are the worst choices to use? Which condition tests are
>> the worst?

>
> Anything that has to directly access eDirectory, the connected
> application, or some external resource are likely to be much more
> expensive than those that only access/modify the current document.
>
>>
>> Not sure if it is ever possible to answer all of this but it might be
>> a fun discussion.

>
>
> --
>
> Father Ramon

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFF8NwE7eGRNwWOK9IRAoG+AJwNJ+Ge/NQyzPr2/VQ7PCld7DjcbwCeN996
LzOqqLfQwdYzPgVt2049P5I=
=lJ0f
-----END PGP SIGNATURE-----