I suspect due to the HTTP overhead: profiling shows a large chunk of time waiting for sockets.
If it waiting, then either it is because Fuseki is doing work (see the
log file which has entries at start and end of an operation), or the
client is waiting (maybe connection management issues?).
Fuseki does keep the connection open (connection caching). If log looks
correct, how long is the client waiting?
Andy
On 26/12/17 03:25, Stefano Cossu wrote:
Dick,
I am interested in hearing the reasons behind your developers dropping
RDFLib, which I find very convenient for de/serializing RDF but I feel
like it is somewhat brittle and quite obscure in the back end connection
part. I think that your approach to using straight HTTP calls for that
may be a better choice.
Also, thanks for the tip on Thrift. I am not familiar with it but I
would be interested in knowing how your team is building Python bindings
for the Jena API if it is meant to become a public project at some point.
Best,
Stefano
On 12/24/2017 04:33 PM, dandh988 wrote:
We use Python against Jena/Fuseki/CustomHTTP and find direct SPARQL
against the endpoint to be "fast". The Python Devs dropped using the
RDFLib.
We also have a Thirft connection in development which is proving
useful for low level Jena API access.
Dick
-------- Original message --------From: Stefano Cossu
<[email protected]> Date: 24/12/2017 22:10 (GMT+00:00) To:
[email protected] Subject: Python bindings?
Hello,
I am writing a LDP server using Python's RDFlib and Fuseki/TDB as a back
end store.
Right now my application is very slow, I suspect due to the HTTP
overhead: profiling shows a large chunk of time waiting for sockets.
Is there a reliable way to write Python code against the Fuseki Java
API? I understand that Fuseki is written in Java and there are no native
Python bindings. I have looked at options such as Jython, Jpype and
PyJnius but I am wondering how reliable these options are. Any
suggestions?
Thanks,
Stefano
