TinkerGraph getLabels() et getTraversals() rendent les tests plus lents

J'ai quelques tests d'intégration utilisant TinkerGraph (en mémoire) qui prennent chacun 10-15 secondes pour finir. De surveillance, en utilisant VisualVM, j'ai compris que la principale cause de retard est due à TraversalHelper.getLabels() et TraversalHelper.getTraversals() méthodes.TinkerGraph getLabels() et getTraversals() rendent les tests plus lents

Je m'attendais à ce que TinkerGraph soit en mémoire pour être rapide mais il se peut que je fasse quelque chose de mal ou qu'il y ait effectivement un problème de performance. Mes autres tests sont à moins de 200ms. Toute aide est appréciée!

Voici une requête qui prend 5+ secondes pour créer 51 sommets avec environ 4-5 propriétés chacune reliées entre elles par 89 arêtes:

PasteBin Example

MISE À JOUR: Performance dans mon les tests ont été améliorés de ~ 40s à ~ 6s pour les tests en mémoire et de 2mins à moins de 1min en utilisant DSE après avoir utilisé les nouveaux 3.2.5-SNAPSHOT et 3.3.0-SNAPSHOT (de http://repository.apache.org/snapshots/). Pour plus de détails, vous pouvez jeter un oeil ici: https://issues.apache.org/jira/browse/TINKERPOP-1642. Je voudrais dire un grand merci à stephen mallette pour son action rapide et précise qui a permis d'améliorer les performances non seulement pour les traversées gremlin en mémoire mais aussi pour toutes les autres technologies de graphe sur disque qui utilisent gremlin par-dessus.

Source

2017-01-29 Michail Michailidis

Quelle est la nature de vos tests? Quelle est la taille de votre graphique de test (c'est-à-dire le nombre d'arêtes)? –

moins de 20 sommets et arêtes. Le test consiste simplement à créer un sous-graphe et à l'insérer dans une seule traversée .. Chaque sommet a un label avec as() J'enverrai les requêtes dans un bit. merci :) –

Cela semble étrange. Une traversée de plus de 20 sommets/arêtes ne devrait pas prendre plus de 10 secondes sur TinkerGraph. Si j'étais vous j'ouvrirais une console de Gremlin, créerais mon graphique de 20 vertex/edge dans TinkerGraph et exécuterais alors les parcours que vous testez pour voir si vous obtenez la même vitesse lente. Si vous le faites, modifiez votre question pour inclure le code Gremlin pour créer le graphique et la traversée causant le problème. Si vous n'obtenez pas la même vitesse lente, vous devez avoir quelque chose d'étrange dans votre environnement de test et vous devrez isoler cela plus avant. –

C'est un morceau assez massif de Gremlin. Honnêtement, je ne sais pas à quoi m'attendre en termes de performance sur un morceau de Gremlin avec plus de 350 déclarations enchaînées.

Je voudrais offrir quelques conseils. Essayer de faire tout ce travail dans une seule ligne de Gremlin crée un code difficile à lire et difficile à maintenir. Vous n'essaieriez probablement pas d'écrire votre code non-Gremlin de cette façon (peu importe la langue dans laquelle vous travaillez), donc il est probablement bon de considérer vos techniques de programmation standard lors de l'écriture de Gremlin. Même si je ne suis pas sûr de ce que la performance devrait être sur ce gros morceau de Gremlin, je sais que si vous divisez cette déclaration en plus petits morceaux plus gérables, la création de 51 sommets et 89 bords ne devrait pas prendre 5+ secondes pour courir. Je ne sais pas trop comment attribuer cette différence, mais vous créez une bonne quantité de frais généraux dans la traversée avec toutes ces étiquettes, ce qui explique peut-être les interminables appels à getLabels() que vous avez mentionnés dans votre question.

Mise à jour: Voir discussion ci-dessous

Source

2017-02-24 12:06:41

Merci! Bien que je ne l'ai pas écrit moi-même .. c'est un test donc il génère des choses à la volée à partir de mappeurs d'objets personnalisés qui peuvent gérer facilement la complexité .. le problème est que dans la production (avec DSE Graph) Pour être dans une seule transaction, j'ai besoin de le faire en une seule requête .. c'est pourquoi j'ai dû prendre cette route .. Malheureusement, il n'y a aucun moyen de faire la mise à jour batch par l'API en une seule transaction. la création est inférieure à 100 donc je suis curieux de savoir s'il y a une mise en cache correcte dans les coulisses .. Je vais enquêter plus loin mais c'est en mémoire! –

Pourriez-vous s'il vous plaît expliquer si ceci: https://github.com/apache/tinkerpop/blob/f5558cd02904c748de3b3cbd403b4858218d5ec1/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/util/TraversalHelper. java # L556 est appelé à chaque étape et si c'est le cas pour toute la traversée jusqu'ici? ou quand il est appelé? Cela semble cher! Merci :) –

nous avons examiné cela, et il semble qu'il est seulement appelé une fois lorsque les exigences de traversée sont récupérées. dans votre cas, vous n'avez pas de récursivité, car vous n'avez pas de parcours imbriqué. il s'agit donc d'une itération de plus de 350 étapes à la recherche d'étiquettes. toujours à la recherche du problème. –

TinkerGraph getLabels() et getTraversals() rendent les tests plus lents

Répondre

Questions connexes