TinkerGraph getLabels() и getTraversals() делают тесты медленными

У меня есть некоторые интеграционные тесты с использованием TinkerGraph (в памяти), которые занимают 10-15 секунд для завершения. Из мониторинга, используя VisualVM, я выяснил, что основная причина задержки связана с методами TraversalHelper.getLabels() и TraversalHelper.getTraversals().TinkerGraph getLabels() и getTraversals() делают тесты медленными

Я ожидал TinkerGraph, так как это встроенная память, которая быстро вспыхивает, но может случиться так, что я делаю что-то неправильно или действительно есть проблема с производительностью. Мои другие тесты меньше 200 мс. Любая помощь приветствуется!

Вот запрос, который занимает 5 + секунд, чтобы создать 51 вершин с 4-5 свойств каждого, соединенных между собой через 89 ребер:

PasteBin Example

UPDATE: производительности в моей тесты были улучшены с ~ 40 до 6 секунд для тестов в памяти и от 2 до менее 1 мин с использованием DSE после использования вновь развернутых 3.2.5-SNAPSHOT и 3.3.0-SNAPSHOT (от http://repository.apache.org/snapshots/). Более подробную информацию вы можете посмотреть здесь: https://issues.apache.org/jira/browse/TINKERPOP-1642. Я хотел бы сказать большое спасибо Stephen Mallette за его быстрое и точное действие, которое обеспечило отличное повышение производительности не только для обходов гремлингов в памяти, но и всех других дисковых графических технологий, которые используют гремлин поверх них.

источник

2017-01-29 Michail Michailidis

Какова природа ваших тестов? Насколько велика ваша тестовая диаграмма (т. Е. Количество ребер)? –

менее 20 вершин и краев. Тест просто создает подграф и вставляет его в один проход. В каждой вершине есть метка с as(), я пошлю запросы немного. спасибо :) –

Это кажется странным. Обход более 20 вершин/ребер не должен занимать 10 секунд на TinkerGraph. Если бы я был вами, я бы открыл консоль Gremlin, создав свой 20 вершинный/краевой граф в TinkerGraph, а затем запустил пройденные вами обходные проверки, чтобы увидеть, если вы получите такую же медленную скорость. Если да, то отредактируйте свой вопрос, чтобы включить код Гремлина для создания графика и обхода, вызывающего проблемы. Если вы не получаете такую же медленную скорость, то вы должны иметь что-то странное в своей тестовой среде, и вам нужно будет выделить это дальше. –

Это довольно массивная часть Гремлина. Я честно не уверен, чего ожидать в плане производительности на куске Гремлина с 350 + цепными заявлениями.

Я бы предложил несколько советов. Попытка сделать все, что работает в одной строке Gremlin, создает код, который трудно читать и его трудно поддерживать. Вероятно, вы бы не попытались написать свой код не-Гремлин таким образом (независимо от того, на каком языке вы работаете), поэтому, вероятно, полезно учитывать ваши стандартные методы программирования при написании Gremlin.

Хотя я не уверен, что производительность должна быть на этом большом куске Гремлина, я знаю, что если вы разделите это утверждение на более мелкие более управляемые биты, создание 51 вершины и 89 ребер не должно принимать 5+ секунд для запуска. Я не знаю, как отнести эту разницу к офису, но вы создаете достаточное количество накладных расходов для себя в обход со всеми этими метками шагов, что, возможно, объясняет бесконечные звонки getLabels(), которые вы упомянули в своем вопросе.

Обновление: См обсуждение ниже

источник

2017-02-24 12:06:41

Спасибо! Хотя я сам этого не писал ... это тест, поэтому он генерирует вещи «на лету» на основе пользовательских Mappers объектов, которые легко справляются со сложностью .. проблема в том, что в производстве (с DSE Graph) для этого чтобы быть в одной транзакции, мне нужно сделать это в одном запросе .. вот почему я должен был пройти по этому маршруту .. к сожалению, нет возможности сделать пакетное обновление через свободный api в одной транзакции. создание меньше чем 100, поэтому мне любопытно, есть ли правильное кэширование за кулисами. Я буду исследовать его дальше, но это в памяти! –

Не могли бы вы объяснить, если это: https://github.com/apache/tinkerpop/blob/f5558cd02904c748de3b3cbd403b4858218d5ec1/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/util/TraversalHelper. java # L556 вызывается на каждом шаге, и если он делает это для всего обхода до сих пор? или когда он действительно называется? Это кажется дорогим! Спасибо :) –

Мы действительно заглянули в это, и похоже, что он вызывается только один раз, когда требуются требования к обходу. в вашем случае у вас нет рекурсии, так как у вас нет вложенного обхода. так что это итерация более 350 шагов, только поиск ярлыков. все еще рассматривая проблему. –

TinkerGraph getLabels() и getTraversals() делают тесты медленными

ответ

Смежные вопросы