L'hébergement Relevanssi dimensionné pour l'index, pas seulement les messages.
Relevanssi construit son propre index à l'intérieur de MySQL, et sur un site riche en contenu, cet index est régulièrement plus grand que chaque message que vous avez écrit. La base de données doit être configurée pour elle.
Tout ce qu'un index soutenu par une base de données demande à un hôte.
Relevanssi n'appelle pas à un service de recherche. Chaque requête et chaque reconstruction se produit dans votre base de données, ce qui fait de ce problème de réglage MySQL.
Un index qui correspond à la mémoire
Le pool tampon InnoDB est dimensionné pour tenir l'index Relevanssi à côté du reste du jeu de travail, donc une recherche lit à partir de la mémoire plutôt que de tirer des pages d'index hors disque une requête à la fois.
Reconstruire cette finition
Un réindex complet sur un grand site va dépasser toute demande de navigateur. Notre fonctionnement de WP-CLI avec le plafond d'exécution relevé, donc le travail complète au lieu de mourir à mi-chemin et laissant un index partiel.
Les pages de recherche restent dynamiques
Les pages de résultat sont par-requête et souvent par-utilisateur, donc elles sont gardées hors du cache de page. Les recherches coûteuses derrière elles sont mises en cache dans Redis, qui est là où la répétition est réellement.
Salle pour les documents longs
Indexer les longs messages, les champs personnalisés et le texte de pièce jointe signifie écrire de grandes lignes. Les limites des paquets et des lignes sont levées de sorte que ces écrits réussissent plutôt que de échouer silencieusement en milieu d'index.
Sauvegardes qui savent que l'indice est restructurable
Le contenu est sauvegardé nuit après nuit et reproduit hors de l'origine. L'index peut être régénéré à partir de lui, de sorte qu'une restauration ne dépend pas d'avoir capturé une copie cohérente d'une table qui change constamment.
Sachez que l'indice est actuel.
Un index de recherche est invisible jusqu'à ce que quelqu'un recherche le post que vous avez publié ce matin et ne trouve rien. Ce sont les choses qui méritent d'être regardées.
- Connexion admin à un clic, pas de mot de passe partagé
- Taille de l'indice suivie du bassin tampon
- Plugin et mises à jour de base avec statut par article
- Restaurer toute sauvegarde quotidienne depuis le tableau de bord
Cherchez les réponses avant qu'elles ne les retypent.
Les requêtes Relevanssi ne peuvent pas être mises en cache au niveau de la page, leur vitesse est donc entièrement déterminée par la mémoire de l'index lorsque la requête arrive.
Ce que nous changeons pour Relevanssi
Ceux-ci diffèrent d'un site WordPress standard sur le même plan, et chacun d'eux existe parce que l'index de recherche vit dans votre base de données plutôt que dans un service séparé.
| Paramètre | Notre configuration | Pourquoi |
|---|---|---|
| Pool tampon InnoDB | Taille de la commande pour tenir l'indice Relevanssi en plus de la commande normale | L'index sur un site riche en contenu dépasse souvent la taille de la table des messages elle-même, et une fois qu'il ne s'intègre plus en mémoire, chaque recherche commence à lire des pages d'index à partir du disque au lieu de RAM. |
| max_allowed_packet | Bien au-dessus de la valeur par défaut pour index écrit | L'indexation de longs messages avec des champs personnalisés et le contenu de la pièce jointe produit des instructions uniques beaucoup plus grandes qu'une installation MySQL par défaut accepte, et les surfaces de rejet comme contenu qui n'est tout simplement jamais trouvé. |
| Reconstruction de l'indice | Exécuter par WP-CLI avec le plafond d'exécution levé, jamais à partir d'une requête de page d'administration | Un réindex complet sur une grande archive fonctionne pendant plusieurs minutes, donc le déclencher à partir du navigateur signifie une requête qui meurt par voie partielle et quitte l'index contenant une partie du site et aucun des autres. |
| Pages de résultats de recherche | Exclus du cache de page; les recherches sous-jacentes mises en cache dans Redis | Chaque page de résultat est spécifique à une chaîne de requête et souvent aux permissions d'un utilisateur, de sorte que la mise en cache de la page est inutile tout en encachant la requête derrière elle supprime le travail répété. |
| Surveillance de la croissance des indices | Taille de la table d'index suivie et alertée contre le pool configuré | L'index augmente avec l'archive plutôt qu'avec le trafic, donc un site qui a été rapide pendant un an se dégrade progressivement sans changement de visiteurs et rien dans le graphique de trafic pour l'expliquer. |
Des tarifs simples et transparents.
Chaque offre comprend la migration gratuite, les sauvegardes quotidiennes, le SSL et l’assistance 24 h/24, 7 j/7.
- 1 site WordPress
- 10 Go de stockage NVMe
- SSL gratuit
- Sauvegardes quotidiennes
- Déploiement en un clic
- Assistance par tickets
- 5 sites WordPress
- 50 Go de stockage NVMe
- SSL gratuit
- Sauvegardes quotidiennes
- Déploiement en un clic
- Assistance prioritaire par tickets
- 20 sites WordPress
- 200 Go de stockage NVMe
- SSL gratuit
- Sauvegardes quotidiennes
- Déploiement en un clic
- Assistance dédiée
Questions fréquentes.
Pourquoi ma recherche Relevanssi est-elle plus lente qu'elle ne l'était auparavant ?
Combien de temps faut-il pour un réindex complet?
Dois-je utiliser Relevanssi ou ElasticPress?
Les pages de résultats de recherche peuvent-elles être mises en cache ?
Mes sauvegardes incluent-elles l'index de recherche ?
Exécutez Relevanssi avec une base de données qui correspond à l'index.
Migration gratuite, un pool tampon dimensionné pour votre archive, et recompile ce qui est terminé.