Повышение производительности оценки команд сервера Gremlin

При вставке десятков тысяч узлов и ребер в tinkerpop с поддержкой cassandra я вижу, что практически все службы в основном простаивают, за исключением сервера Gremlin. То есть клиент, подключенный к веб-сокету и отправляющий команды в формате Gremlin, не потребляет много процессорного времени, как и Cassandra или ElasticSearch. Gremlin Server, с другой стороны, использует несколько процессоров (на довольно мощной машине с десятками ядер и сотнями гигабайт оперативной памяти).

Увеличение количества рабочих потоков GS не оказывает положительного влияния. Увеличение количества одновременных разрешенных запросов веб-сокетов (настройка клиента) также не помогает. Как ни странно, неограниченное количество одновременных запросов веб-сокетов приводит к тому, что данные не могут быть вставлены без каких-либо ответов на сообщения об ошибках HTTP.

Рабочая теория состоит в том, что узким местом сервера gremlin является оценка команд Gremlin (g.addV и т. Д.). Есть ли у кого-нибудь опыт получения высоких показателей загрузки с помощью плагина websocket, или мне необходимо написать собственный плагин JVM langauge, который работает с двоичными данными, чтобы избежать синтаксического анализа и оценки строк?

РЕДАКТИРОВАТЬ: сценарии представляют собой пакеты до 100 операторов вставки вершин или вставок ребер / вершин / ребер:

Вставки вершин:

graph.addVertex(label, tyParam, 'ident', vertexName, param1, val1, param2, val2 ...) ;
graph.addVertex(...) ; 
...

Для троек ребро, вершина, ребро:

edgeNode = graph.addVertex(...) ; 
g.V().has('ident',var).next().addEdge(var2,edgeNode) ;
edgeNode.addEdge(var3, g.V().has('ident',var4).next())

Идентификатор индексируется узлом, поэтому .has должен работать быстро. К сожалению, набор данных включает ребра для несуществующих источников или мест назначения, что вызывает ошибку FastNoSuchElementException. В случаях ошибки мы разделяем набор операторов пополам и повторяем скрипт как две меньшие попытки вставки. Например, сценарий с ошибкой 50 операторов вставки ребра / вершины / ребра становится двумя сценариями из 25, и этот процесс продолжается вплоть до сценария с одной вставкой e / v / e, где любой сбой игнорируется.

N.B. Я использую Titan 1.0.