Optimisation des pages de destination

Question

Dans mon projet actuel (Rails 2.3), nous avons une collection de 1,2 million de mots clés, chacun associé à une page de destination, qui est en fait une page de résultats de recherche pour un mot clé donné. Chacune de ces pages est assez compliquée, ce qui peut prendre beaucoup de temps à générer (jusqu'à 2 secondes avec une charge modérée, voire plus pendant les pics de trafic, avec le matériel actuel). Le problème est que 99,9% des visites sur ces pages sont de nouvelles visites (via les moteurs de recherche), donc cela ne sert pas à grand chose de le mettre en cache lors de la première visite: il sera encore lent pour cette visite. être dans plusieurs semaines. Je voudrais vraiment faire ces pages plus rapidement, mais je n'ai pas trop d'idées sur la façon de le faire. Deux ou trois choses qui viennent à l'esprit:

• construire un cache pour tous les mots clés au préalable (avec un TTL très long, un mois). Cependant, construire et maintenir ce cache peut être très pénible, et les résultats de recherche sur la page peuvent être périmés, ou même plus accessibles; Compte tenu de la nature volatile de ces données, n'essayez pas de mettre en cache quoi que ce soit, et essayez simplement de faire évoluer le trafic.

J'apprécierais vraiment toute rétroaction sur ce problème.

Answer 1

Quelque chose ne va pas exactement de pair avec votre description. Quand vous dites que 99,9 p. 100 sont de nouvelles visites, c'est vraiment sans importance. Lorsque vous mettez en cache une page, vous ne la cachez pas uniquement pour un visiteur. Mais peut-être que vous dites que pour 99,9% de ces pages, il n'y a qu'un seul hit toutes les quelques semaines. Ou peut-être que vous voulez dire que 99,9% des visites se font sur une page qui ne reçoit que rarement?

Dans tous les cas, la première chose que je voudrais savoir est de savoir s'il existe un pourcentage important de pages qui pourraient bénéficier de la mise en cache de la page entière. Qu'est-ce qui définit une page comme bénéficiant de la mise en cache? Eh bien, le ratio des hits aux mises à jour est la mesure la plus importante ici. Par exemple, même une page qui ne serait touchée qu'une fois par jour pourrait bénéficier considérablement de la mise en cache si elle ne devait être mise à jour qu'une fois par an.

Dans de nombreux cas, la mise en cache des pages ne peut pas faire grand-chose, alors vous devez vous pencher sur plus de détails. Tout d'abord, profilez les pages ... quelles sont les parties les plus lentes à générer? Quelles parties ont les mises à jour les plus fréquentes? Y a-t-il des parties qui dépendent de l'état de connexion de l'utilisateur (cela ne sonne pas comme si vous aviez des utilisateurs?)?

Le fruit le plus bas (et ce qui va se propager dans tout le système) est une bonne vieille optimisation. Pourquoi faut-il 2 secondes pour générer une page? Optimisez l'enfer de votre code et magasin de données. Mais ne va pas faire des choses comme bonjour, en supprimant tous les assistants de Rails. Toujours le profil en premier (NewRelic Silver and Gold sont extrêmement utiles pour obtenir des traces de l'environnement de production réel.) Cela vaut vraiment le coût) Optimisez votre magasin de données. Cela peut être dû à la dénormalisation ou, dans les cas extrêmes, au passage à une technologie DB différente. Une fois que vous avez effectué toutes les stratégies d'optimisation directe raisonnables, observez la mise en cache des fragments. La partie la plus chère des pages les plus fréquemment consultées peut-elle être mise en cache avec un bon ratio de mise à jour? Méfiez-vous des solutions compliquées ou nécessitant une maintenance coûteuse. S'il y a une règle cardinale pour optimiser le coût de l'évolutivité, c'est que vous avez besoin de suffisamment de RAM pour tout ce que vous avez besoin de servir régulièrement, car cela vous donnera toujours plus de débit que l'accès au disque. être à ce sujet. Combien doit être en RAM?Eh bien, je n'ai pas beaucoup d'expérience à des échelles extrêmes, mais si vous avez un conflit d'E/S sur disque, vous avez certainement besoin de plus de RAM. La dernière chose que vous voulez, c'est un conflit IO pour quelque chose qui devrait être rapide (c'est-à-dire la journalisation) parce que vous attendez un tas de choses qui pourraient être en RAM (données de page).

Une note finale. Toute évolutivité concerne vraiment la mise en cache (registres de l'UC> cache L1> cache L2> RAM> lecteurs SSD> lecteurs de disque> stockage réseau). C'est juste une question de grain. La mise en cache des pages est extrêmement grossière, simple et trivialement évolutive si vous pouvez le faire. Toutefois, pour les ensembles de données volumineux (Google) ou les contenus hautement personnalisés (Facebook), la mise en cache doit se faire à un niveau beaucoup plus précis. Dans le cas de Facebook, ils doivent optimiser jusqu'à l'actif individuel. En substance, ils doivent faire en sorte que n'importe quel élément de données peut être consulté en quelques millisecondes de n'importe où dans leur centre de données. Chaque page est construite individuellement pour un seul utilisateur avec une liste personnalisée d'actifs. Tout cela doit être mis en place dans < 500ms.