Partager via


Conseils divers sur les performances RPC

Cette section décrit divers conseils de performances pour le développement de serveurs RPC hautes performances. Cette section fournit de nombreux conseils qui font référence au client RPC. Le développement d’un client RPC permet au serveur RPC d’effectuer moins de travail.

Utiliser Kerberos

Si la sécurité est utilisée, utilisez Kerberos. Côté serveur, Kerberos ne nécessite pas d’accès au KDC. Cela déplace la charge de travail du serveur vers le client, ce qui offre des serveurs plus performants.

Utiliser le suivi des identités statiques

Si la sécurité est utilisée, essayez d’utiliser le suivi des identités statiques. Le suivi des identités statiques est moins cher en termes d’utilisation des ressources que le suivi des identités dynamiques. Si l’identité du client change et que le serveur ne doit pas connaître la modification, utilisez le suivi dynamique au lieu de créer un handle de liaison différent pour chaque identité. Toutefois, si l’identité est identique, assurez-vous que RPC est conscient de ce fait pour éviter d’avoir des vérifications de l’identité modifiée à chaque fois.

Utiliser la fonction RpcGetAuthorizationContextForClient

Si vous devez vérifier l’accès dans Windows XP, utilisez la fonction RpcGetAuthorizationContextForClient. Les contextes d’authentification résultants permettent des vérifications d’accès très rapides, qui sont efficacement mises en cache par l’heure d’exécution RPC.

Ne modifiez pas le jeton, sauf si nécessaire

Si le suivi des identités dynamiques est utilisé, ne modifiez pas le jeton thread/processus, sauf si absolument nécessaire. Même s’il est modifié pour les paramètres qu’il avait précédemment, le jeton est souvent suffisamment différent du système de sécurité pour déclencher l’établissement d’un nouveau contexte de sécurité.

Envisagez la sérialisation en mode mixte pour les handles de contexte

Le mode de sérialisation par défaut pour le handle de contexte est sérialisé (exclusif). Envisagez d’effectuer tous les appels qui ne modifient pas l’état du handle de contexte en mode de sérialisation partagée. Pour plus d’informations, consultez RpcSsContextLockExclusive.