dsp-api

dsp-api copied to clipboard

I've done some testing/research. Here are the findings.

• GraphDB-Free:
  • max number of concurrent connections is limited to 2 by the license.
• GraphDB-SE:
  • max number of concurrent connections is "unlimited" but the number of cores that are used is limited by the license.
  • Depending on the number of HttpTriplestoreConnection actors that we have in the pool, i.e. how many concurrent connections we open, Graphdb creates a different amount of threads
  • 10 concurrent connections ~ 32 threads
  • 20 concurrent connection ~ 42 threads
  • 100 concurrent connections ~ 128 threads (this is the maximum that was created)
  • the number of threads created is independent of the license, i.e. the same number of threads with the 1 core and 8 core license
  • When GraphDB is freshly started, it starts with 29 threads. Only after the first concurrent request hit GraphDB, it starts to raise the number of threads (which takes time). This is the reason why the first requests take much longer.

I've used ab -n 100 -c 100 http://localhost:3333/v1/resources/http%3A%2F%2Frdfh.ch%2F047db418ae06 to do some tests with 10, 25, 50, 100 actors in the HttpTriplestoreConnection actor pool. There are some differences, but not massive, i.e. having 10 actors vs 100 actors only speeds up the slowest request by ~300 ms while the fastest request is slowed down by ~200 ms. Also, the times measured are all over the chart. One time the slowest request is around 1500 ms and the next 2500 ms and then back again to 1800 ms. We need some automated for testing, where the measued data is written in a database and we can look at some charts.

So in conclusion, I would say that the default number of 10 actors in the HttpTriplestoreConnection pool is OK. For production, we will need to do some more testing, to see what the optimal settings are.