# Préface

Lors de la construction de [ce site] (https://tstrs.me), j’ai utilisé ElasticSearch comme base de données Redis comme composant de cache, qui a été utilisé sans aucun problème au début, puis en raison de l’itération de version, de l’ajout de modules et de l’amélioration continue des pages. Dans de nombreux endroits, les données doivent être remplies avec Redis, et même certaines pages doivent être interrogées des dizaines ou des centaines de fois, ce qui ralentit la vitesse de chargement et augmente la charge du système. Cette rubrique se concentre sur la correction des bogues de site Web, l’optimisation de la charge système et le réglage des stratégies de cache.

# Introduction aux modules système

Contenu du corps

Parce que je n’avais pas prévu d’importer d’anciens articles de blog dans le nouveau système au début, j’ai conçu un nouveau format de lien de page, c’est-à-dire: '\result\article ID', parce que cet ID est unique et que la longueur est fixée à 20 bits, donc la paire clé-valeur (KV) que j’ai conçue dans le système de mise en cache est l’ID d’article: contenu de l’article, par exemple:

hXia44YBlyC2E8nCuWW5:[Contenu de l’article]

L’avantage de ceci est que c’est très simple et rapide, lorsque vous devez demander si un article est mis en cache, vous pouvez vérifier directement l’ID, sinon, il sera déposé dans la base de données puis jeté à Redis.

Lectures recommandées

Plus tard, [Lecture recommandée] a été ajouté sur le côté de la page, initialement en utilisant la requête de popularité ElasticSearch, puis a estimé que la liste de popularité était fondamentalement inchangée et dénuée de sens, elle a donc été changée en retour aléatoire, de sorte que chaque actualisation change. Mais chaque requête à ElasticSearch est lente, j’utilise donc la fonction randomkey de Redis, qui peut renvoyer aléatoirement une clé, puis j’obtiens les détails de l’article en fonction de la clé.

Tout d’abord, le contenu recommandé ici ne peut pas être répété, et deuxièmement, parce que mon site Web est bilingue en anglais et en chinois, je ne peux pas toujours recommander des articles en anglais sur la page chinoise, et vice versa.

Donc, dans ce module, j’ai utilisé une boucle while, un total de 10 entrées, chaque fois qu’il obtient et revient immédiatement après la requête, pour déterminer si le langage est cohérent avec le contenu du corps, s’il est cohérent, ajoutez et comptez +1 jusqu’à ce que le compte atteigne 10. Certaines personnes peuvent ne pas comprendre, ce qui suit est cette partie du code du module, entrez L pour la langue: '''java def getrandomkeyredis(l): #随机获取文章 idlist = []#id rawinfolist = []#详细内容 tandis que len (rawinfolist) < 11:#直到列表大于11停止 onepagesid = str(pagecache.randomkey(), 'utf-8')#从redis extrait de manière aléatoire une déclaration de données et des données octet à chaîne Si onepagesid n’est pas dans idlist :#不在列表内 pcs = getpc(onepagesid) #获取文章详情 if pcs['language'] == l :#语言一致 a = {['Détails de l’article']}#构造返回 rawinfolist. Ajouter a) #将构造好的返回打包到组里面 idlist. Ajouter(onepagesid) #计数 Retour rawinfo_list

Tout d’abord, la raison du langage ici, vous devez interroger à chaque fois pour savoir si ces données peuvent être utilisées, et il faut 30 à 40 fois pour compléter le retour de construction pour chaque requête, mais même ainsi, c’est plus rapide que d’utiliser ElasticSearch directement.

### Regardez autre chose
Maintenant, j’ai ajouté « Regardez autre chose » au bas de la page de l’article, qui est différent de la barre latérale, c’est de style carte. Et à cette époque, afin d’être pratique et rapide, la barre latérale ne retournait que quatre champs: « nom, lien, heure, popularité », et elle avait deux autres champs, à savoir « image de prévisualisation, introduction », pour lequel j’ai créé un module séparé, mais la partie code était fondamentalement la même avec seulement quelques modifications.
![](https://pic.saltyleo.com/i/17108282981.webp)

Bien que l’interface soit belle et que le contenu soit riche, en raison de trop de requêtes, chaque page a essentiellement besoin de 80 à 100 ms pour sortir, ce qui est inacceptable pour moi, et des lectures et des écritures fréquentes d’E/S feront décaler le système, ce qui rend la vitesse d’accès qui n’est pas rapide encore plus lente.

C’est le trou que j’ai creusé auparavant, et je les ai récemment tous optimisés. Les idées de solution et le code réel sont partagés ci-dessous.

## SOLUTION AUX BUGS
Tout d’abord, ce problème se résume au fait que l’architecture globale ne peut pas suivre les besoins des itérations de version ultérieures, et certains modules de base doivent être refactorisés pour résoudre ce problème. À cet égard, j’ai directement soulevé la table et l’ai réengagée, au lieu d’optimiser l’ancien code, il valait mieux couper rapidement le désordre et refactoriser.

Je me suis basé sur les 10 articles sur le côté de la page de détail de mon article plus 6 en bas, pour un total de 16 ensembles d’informations. Obtenez directement 16 retours aléatoires pour la langue correspondante dans la base de données ElasticSearch, et chaque retour ne reçoit que 6 enregistrements, à savoir: 'nom, lien, heure, popularité, carte d’aperçu, introduction', ce qui économise de la mémoire. Le code de requête est le suivant :

es.search(index="why », body={"query »:{"bool »:{"must »:{"multimatch »:{"query »:'tttt',"fields »:['so']}},"filter »:{"match »:{"language »:l}} ,"mustnot »:{"match »:{"edit »:' Modification '}}}}},"from »:0,"size »:16,"sort »: {"_script »: {"script »: « Math.random() »,"type »: « number"}}})

Traduit en mots humains, c’est [donnez-moi le langage de requête de la base de données avec L et les articles qui ne sont pas en cours d’édition, et renvoyez aléatoirement 16 données]. Le 'tttt' dans query est le paramètre de requête générique que j’ai défini. Afin de résoudre fondamentalement le problème de la langue, j’ai directement séparé les bibliothèques Redis chinoise et anglaise, afin de ne pas perdre de temps de requête.

Écrivez le contenu de la requête ci-dessus à Redis, la clé que j’utilise à l’heure actuelle, je n’en ai pas besoin de toute façon, juste la seule.

def setrdm(l): #给redis添加一组缓存, correspondant à la langue correspondante si l == 'zh': zhrdmcache.set(round(time.time()),json.dumps(esact.random(l)),ex=3600) elif l == 'en': enrdmcache.set(round(time.time()),json.dumps(esact._random(l)),ex=3600)

Il est également très simple à lire, et vous pouvez lire la lecture recommandée dans la langue correspondante en utilisant le code suivant.

def getrdm(l): Obtenir un ensemble de retours aléatoires en #从 redis, correspondant à la langue correspondante
si l == 'zh': return json.loads(zhrdmcache.get(zhrdmcache.randomkey())) elif l == 'en': return json.loads(enrdmcache.get(enrdm_cache.randomkey())) ```

Après cette opération, chaque page n’a besoin d’interroger le corps qu’une seule fois, et une recommandation aléatoire, et la consommation totale de temps peut essentiellement être inférieure à 10 ms.

# Post-scriptum

Donc, plus les choses sont simples, plus vite et il est facile de gaspiller des performances, et vous ne ressentez peut-être pas beaucoup de changement sur un serveur avec de fortes performances, mais un peu d’optimisation sur un serveur avec une configuration inférieure peut apporter une énorme amélioration.