Currently it's ran on granet with the CLI: /opt/swhgraph_venv/bin/python3 /opt/swhgraph_venv/bin/swh graph rpc-serve -g /dev/shm/swh-graph/default/graph
This means it uses a single process, which is currently the bottleneck when processing a dozen queries in parallel.
The app path is a bit different from other packages, it's swh.graph.server.app:make_app_from_configfile()
| Status | Assigned | Task | ||
|---|---|---|---|---|
| Migrated | gitlab-migration | T3623 Run swh-graph with gunicorn to support multiple/parallel requests | ||
| Migrated | gitlab-migration | T3624 Update swh-graph from 0.3.0 to 0.5.0 on granet |
Hmm actually this might be harder than just using gunicorn, because the java subprocess needs to be shared between workers, hmm...
I see there are some unapplied performance improvements in swh-graph, let's try that first.
actually, before it starts leaking RAM, the Java process only uses 10% of the memory, so there is room to start a few more.
(Even if, ideally, it would be shared)
Obsoleted by the migration to GRPC. Now we use GRPC's threading model, with a threadpool configurable by passing --threads to the Java service. By default, nproc is used.