IanEmmons
commented
4 years ago Parliament has a many readers/single writer model of concurrency. In other words, if Parliament receives several requests at once, and all of them are read-only requests (such as a query), then Parliament will execute those requests in parallel. Whenever Parliament receives a request that requires writing (such as an insert, SPARQL Update, create/drop graph, etc.), that request will wait until all other executing requests are finished, and then it will execute. And while it is executing, all other requests will wait in the queue until it is finished.
This model works well in most situations, where the number of concurrent requests is not terribly large and read-only requests dominate. A dozen or two concurrent queries is not uncommon in my experience, and does not cause problems. I would expect that Parliament will handle 128 concurrent read-only requests correctly, but the performance may not be as high as one would like. Mainly this is because all those requests ultimately are reading from the same I/O device. Therefore, caching becomes the key issue for concurrency levels this high.
Parliament uses four pools of memory:
- The Java heap (to configure, see "Parliament's Startup Scripts " in Section 2.2)
- Berkeley DB's cache (to configure, see "Parliament’s Main Configuration File" in Section 2.2, under the key bdbCacheSize)
- The C++ heap (not configurable)
- The operating system's demand-paged mappings of memory-mapped files (not configurable)
Achieving the right balance between these pools of memory is tricky, and I'm afraid I don't have any concrete advice, especially in the case of 128 concurrent requests. However, there are a few things I can say:
- Don't make the Java heap too big. Many Java programmers are used to setting their Java heap as big as possible, but for Parliament, the Java heap is not as important as the Berkeley DB cache and the memory-mapped files.
- Parliament currently has a bug (issue #29) that applies the Berkeley DB cache size on a per-graph basis. So if you have 100 named graphs, each graph gets its own cache. I plan to fix this bug in the next release, so that there is one Berkeley DB cache across all the graphs.
- The guidance in the User Guide for the size of the Berkeley DB cache is probably too low.
As before, please leave this issue open as a reminder to me to improve the documentation.
I want to perform queries by upto 128 number of parallel/concurrent workers. Can you recommend some specific configuration please? I want to measure the QpS (queries per second) value of many triple stores for parallelism (querying by more than one user at a time).