Partager via


Conseils de performances RPC divers

Cette section présente divers conseils en matière 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 correctement 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 fournit des serveurs plus performants.

Utiliser le suivi des identités statiques

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

Utiliser la fonction RpcGetAuthorizationContextForClient

Si vous devez case activée accès dans Windows XP, utilisez la fonction RpcGetAuthorizationContextForClient. Les contextes Authz résultants permettent des vérifications d’accès très rapides, qui sont efficacement mises en cache par le temps d’exécution RPC.

Ne pas modifier le jeton sauf si nécessaire

Si le suivi dynamique des identités est utilisé, ne modifiez pas le jeton de thread/processus, sauf si cela est absolument nécessaire. Même s’il est modifié aux 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é.

Envisager 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 .