envoyproxy/envoy

possible optimization: repetitive private key reads

Open

#20 045 ouverte le 18 févr. 2022

Voir sur GitHub
 (5 commentaires) (0 réactions) (0 assignés)C++ (5 373 forks)batch import
area/perfarea/tlsenhancementhelp wanted

Métriques du dépôt

Stars
 (27 997 stars)
Métriques de merge PR
 (Merge moyen 8j) (378 PRs mergées en 30 j)

Description

Title: possible optimization: repetitive private key reads

Description: When investigating https://github.com/envoyproxy/envoy/issues/19774, I found another area that may be improved (possibly). Currently, for each cluster/listener, we do a full boringssl processing of the same key/cert pair (I think). This ends up being fairly expensive at scale. With a large number of clusters, startup time is decreased from 5.5s to 4.5s in my tests when using 2048 bit RSA keys vs ECDSA keys (since they are cheaper to process).

RSA: 2022-18-02_09-39-12

ECDSA: 2022-18-02_09-39-03

I know very little about boringssl or the lifecycles here, but my naive thought is that it could be read once and shared among each cluster

cc @lambdai

Guide contributeur

Direction de recherche
Examinez comment les clés privées sont lues par cluster/listener et explorez la mise en cache du résultat du traitement de la clé pour le partager entre plusieurs clusters.
Stack technique
ccpp
Domaine
backendinfrastructurecloudnetworking
Type d'issue
Performance
DifficultéDifficulté estimée pour un nouveau contributeur, de 1 pour un très petit changement à 5 pour un travail expert.
3
Temps estiméFourchette de temps approximative pour investiguer, implémenter, tester et préparer une pull request.
1-3 heures
Statut d'activitéDisponibilité apparente de l'issue : fraîche, active, ancienne, bloquée ou en attente d'un mainteneur.
Active
ClartéClarté avec laquelle l'issue explique le changement attendu, les critères d'acceptation et la prochaine étape.
Claire
Prérequis
C++BoringSSL
Accessibilité débutantScore de 1 à 100 estimant l'accessibilité de cette issue pour un premier contributeur.
55