J'ai une exigence générale dans mon projet actuel de faire une application XPage existante plus rapidement. Une chose que nous avons examinée était de savoir comment accélérer des champs plus lents de type-devant, et une solution à cela qui semble être rapide, la mise en œuvre à l'aide de FTSearch plutôt que le DBColumn que nous avions à l'origine. Je souhaite obtenir des conseils sur le point de savoir si ce serait une approche ok, ou s'il y a des suggestions pour faire ce dont nous avons besoin d'une manière différente.
arrière-plan: Bien qu'il existe un certain nombre de facteurs affectant la vitesse (comme la latence réseau, le système d'exploitation du serveur, la mémoire de serveur disponible, etc.), comme nous utilisons 8.5.3, nous avons optimisé l'application en général aussi loin que possible, en utilisant le IBM Toolkit Pour trouver des problèmes de problèmes et utiliser également les fonctions IBM ajoutées pour aider à cela en 8.5.3 (par exemple, exécution partielle, à l'aide de l'option JS et CSS optimisée, etc.). Malheureusement, nous sommes bloqués avec le serveur exécutant sur un système d'exploitation Windows 32bit avec une RAM de 3,5 Go pendant quelques mois.
L'un des éléments les plus lents à réagir est dans certains types d'avant qui font référence à un grand nombre de documents. Le pire on en moyenne environ 5 ou 6 secondes avant que la liste suggérée apparaisse pour un champ compatible de type à venir. Il utilise des SSJS pour appeler une classe Java pour effectuer un appel dbcolumn (utilisant des xpages de ferry Kranenburg snippet ) Pour obtenir une liste unique à partir d'une vue, puis revenir en SSJ, il boucle le tableau pour vérifier si chaque entrée contient le Valeur de la clé de recherche, et si vous avez trouvé qu'il ajoute une balise HTML de surbrillance (gras) autour du texte de recherche dans le mot, puis renvoie la liste formatée sur le navigateur. J'ai ajouté une déclaration d'impression pour produire le temps écoulé qu'il faut pour exécuter le code et en moyenne aujourd'hui sur notre serveur Dev, il est d'environ 3250 ms.
J'ai essayé quelques choses pour voir comment nous pourrions faire ce processus plus rapidement:
a ajouté une classe Java pour effectuer tous les traitements (afin de ne pas utiliser SSJS). Cela n'a sauvegardé qu'une moyenne de 100 ms.
Utilisation d'un haricot géré sur scopé de vue, j'ai chargé la liste de recherche unique en mémoire lorsque la page est chargée. Cela produit une réponse très rapide de type à l'avance (16 ms), mais je suppose que c'est une mauvaise façon de le faire toujours dans une classe Java - au lieu d'effectuer un DBLOOKUP pour obtenir la "liste" de toutes les valeurs à rechercher, j'ai le code d'exécuter une recherche FT pour obtenir la collection DOC, puis boucle chaque DOC à extraire La valeur du champ que je souhaite et ajoutez-les à un "tri" (qui ne permet pas automatiquement les doublons), puis boucle le réglage de tri pour insérer les balises en gras autour du terme de recherche et renvoyer cela au navigateur. Cela prend en moyenne 100 ms - ce qui est grand et à peine perceptible. Y a-t-il des inconvénients à cette approche - ou des raisons pour lesquelles je ne devrais pas le faire de cette façon?
Merci pour des commentaires ou des conseils à ce sujet.
Pam.
Mise à jour août, 14. 2013: J'ai essayé une autre approche (inspirée de la demande IBM / Tony McGuckin Insights sur OpenNTF ) Comme le type de recherche de la société est à l'avance à l'aide de haricots gérés et est rapide sur beaucoup de données.
4. Bien que l'application Insights traite des données divisées sur plusieurs bases de données, le principe de type-devant est similaire. Je ne pouvais pas utiliser de vue avec getallentriesbykey si nécessaire pour rechercher une chaîne dans le texte aussi, pas seulement au début de l'entrée. J'ai essayé de créer une vue d'opinion basée sur une vue ftsearch, mais comme nous avons beaucoup de noms en double dans la colonne, cela n'a pas donné la liste unique que je voulais. J'ai ensuite essayé d'utiliser un northviewnavigator sur une vue classée et en boucle à travers cela. Cela a produit la liste unique dont j'avais besoin, mais il s'est avéré plus lent que l'une des autres méthodes ci-dessus. (J'ai mis en œuvre Ces TIPS DE PERFORMANCE DE VIEWNAVIGATOR).
3 Réponses :
de mon point de vue, performance peut être affectée par tout De nombreuses couches, chaque application domino (non seulement Xpages) est constituée. Du haut - navigateur (DOM, JS, CSS, HTML ...), réseau (latences, DNS, SSO ...) à la couche d'application (algorithmes efficaces, caches), base de données / API (quantité de données, index, noms de lecteurs ...) et le système d'exploitation / matériel (disques, mémoire ...)
Selon les choses que vous avez testées:
Ma suggestion est la suivante: aller pour ft, si cela résout votre problème. Certainement, Dépannage FT Performances dans un test de performance lourde sur votre serveur Premièrement.
Merci pour votre réponse. Et merci d'avoir tapé la faute de frappe! - Je l'ai corrigé maintenant.
(Je ne peux pas commenter à cause de ma faible réputation)
Je me suis récemment abordé avec un problème similaire. Voici quelques points supplémentaires à prendre en compte:
Y a-t-il de nombreux mots clés en double dans la vue? Envisagez de faire une vue classée pour @DBColumn.
ftsearching Une vue est souvent plus lente qu'une base de données, je crois. Voir André Guirard's Article . Pensez à utiliser L'index FT peut être mis à jour par programmation avec La consommation de mémoire peut être vérifiée de cette manière:
À la fin, je pense qu'il n'y a pas de réponse générale unique à votre question. Vous devez tester différentes approches pour trouver la solution la plus rapide dans votre environnement. db.ftsearch () et affinant votre requête FT pour inclure la sélection de la vue @formula, si possible.
db.updateftindex () . Si des mots-clés sont rarement ajoutés, mais il faut être instantanément disponible, vous pouvez effectuer une mise à jour de l'index dans l'événement QuerySave du document clé (ou similaire). Nous avons utilisé cette approche lorsque les mots-clés ont été stockés dans une base de données différente (beaucoup plus petite) et la mise à jour était très rapide.
Merci pour les suggestions. J'ai quelques choses là pour regarder.
Un problème avec la recherche FT est cette erreur:
L'index complet de texte de cette base de données est utilisé
Sur la base de mon expérience, cela se produira pendant un moment (peut-être quelques secondes) lorsque la tâche d'indexeur commence à indexer la base de données. Si vos utilisateurs ne sont pas très exigeants, ils ne peuvent que réessayer et cela fonctionnera probablement.
Mais dans de nombreux cas, vous souhaitez minimiser les erreurs que les utilisateurs obtiennent et devront gérer cette erreur bien. J'ai construit ma propre méthode
ftsearch qui attend un peu et essaie à nouveau jusqu'à ce que l'erreur ne soit pas reçue. Cela montrera comme lenteur à l'utilisateur au lieu de l'erreur.
C'est intéressant - merci. Je vais devoir voir quels sont les résultats alors que la tâche de l'indexeur commence.
Excellent détail dans la question!
Pourquoi mettez-vous en cache les listes dans la vue à chaque fois que la page est ouverte? Sauf si la liste est spécifique à l'utilisateur, je l'ai mis en cache dans les applicationsCOPE et la mise à jour lorsque la liste change (par exemple lorsqu'un document a été ajouté / supprimé).
Merci Mark. Je pense que je ne l'ai placé que dans la vue, de sorte que l'objet n'était pas en mémoire trop longtemps. Je pense parce que c'est si grand, ce ne serait pas bon pour ce problème. D'autres petites quantités de données - je vais certainement regarder en placement dans les applicationsCope à l'avenir.
Tout dépend de ce que vous essayez de faire et de la taille de votre ensemble de données. Si l'application est utilisée beaucoup / par beaucoup de personnes / performances est critique, pourquoi ne pas coller les données dans l'Appscope? BTW: Pour voir une FTSearch Timeahead sur un carnet d'adresses de 40 000 documents en action, consultez ma démo Select2 à bootstrap4xpages.com .