It sounds like processing of the proxy auth control in the backend server has quite a big impact. It would be good to profile this and find out where the time is being spent, i.e. by profiling both "with PAC" and "without PAC" test cases above. AFAICS there's two extra costs incurred as a result of the proxy auth control:
- resolving the authorization ID to a user: internal search (identity mapper), query group membership, privileges, etc
- additional access controls: does the proxy user have the right to perform operations on behalf of the user represented by the authorization ID?
We may be able to improve resolution by caching the proxied user's entry in the entry cache. A step further might be to cache all the authorization information for the last proxied user. I think this could work well for our most common use where AM/IDM is accessing DS via a proxy layer always using the same authorization ID. An alternative is for the proxy to support an alternative mechanism instead of proxy auth, but I've never been a fan of such approaches: typically they involve mapping a single incoming client connection to multiple devoted connections to backend servers, which can become painful if there are lots of clients or if clients are short lived.