We have some python scripts to execute both sparql queries and "updates" (an insert/delete). Here is most of the relevant code (I think):
server = "localhost"
repo = "test"
query_endpoint = "http://%s:8080/openrdf-sesame/repositories/%s" % (server,repo)
update_endpoint = "http://%s:8080/openrdf-sesame/repositories/%s/statements" % (server,repo)
def execute_query(query):
params = { 'query': query }
headers = {
'content-type': 'application/x-www-form-urlencoded',
'accept': 'application/sparql-results+json'
}
(response, content) = httplib2.Http().request(endpoint, 'POST', urllib.urlencode(params),headers=headers)
return (response,ast.literal_eval(content))
def execute_update(query):
params = { 'update': query }
headers = {
'content-type': 'application/x-www-form-urlencoded',
'accept': 'application/sparql-results+json'
}
(response, content) = httplib2.Http().request(update_endpoint, 'POST', urllib.urlencode(params),headers=headers)
return True
All of our calls to execute_query are very fast, less than 1 second to complete. However, any call to execute_update takes a really long time to (16 seconds) the first time. Every call after the first one runs in less than 1 second. We're running sesame version 2.7.12 (we thought upgrading from sesame version 2.7.3 might help, but it didn't much). We only have 2 or 3 thousand triples. This is all running from CGI scripts so we can't really just keep a python session alive to make update calls (anyway isn't that workbench's job?). Any ideas on what is taking so long on that first call to the update_endpoint? Are other people having the same issue? Any suggested resolutions?
Thanks!
EDIT I followed RobV's advice, but I'm still having the same problem. Log files from tshark:
22.577578 10.10.2.43 -> 10.10.2.43 HTTP POST /openrdf-sesame/repositories/test HTTP/1.1
22.578261 10.10.2.43 -> 10.10.2.43 HTTP Continuation or non-HTTP traffic
22.583422 10.10.2.43 -> 10.10.2.43 HTTP HTTP/1.1 200 OK (application/sparql-results+json)
22.583857 10.10.2.43 -> 10.10.2.43 HTTP Continuation or non-HTTP traffic
22.591122 10.10.2.43 -> 10.10.2.43 HTTP POST /openrdf-sesame/repositories/test/statements HTTP/1.1
22.591388 10.10.2.43 -> 10.10.2.43 HTTP Continuation or non-HTTP traffic
35.020398 10.10.2.43 -> 10.10.2.43 HTTP HTTP/1.1 204 No Content
35.025605 10.10.2.43 -> 10.10.2.43 HTTP POST /openrdf-sesame/repositories/test/statements HTTP/1.1
35.025911 10.10.2.43 -> 10.10.2.43 HTTP Continuation or non-HTTP traffic
35.040606 10.10.2.43 -> 10.10.2.43 HTTP HTTP/1.1 204 No Content
35.045937 10.10.2.43 -> 10.10.2.43 HTTP POST /openrdf-sesame/repositories/test/statements HTTP/1.1
35.046080 10.10.2.43 -> 10.10.2.43 HTTP Continuation or non-HTTP traffic
35.049359 10.10.2.43 -> 10.10.2.43 HTTP HTTP/1.1 204 No Content
35.053776 10.10.2.43 -> 10.10.2.43 HTTP POST /openrdf-sesame/repositories/test/statements HTTP/1.1
35.053875 10.10.2.43 -> 10.10.2.43 HTTP Continuation or non-HTTP traffic
35.056937 10.10.2.43 -> 10.10.2.43 HTTP HTTP/1.1 204 No Content
You can see the large gap on the first call to the /statements endpoint.
When we created the repository we created it as a "In Memory Store" repository. I created a new repository of the "Native Java Store" type, and now my first call is fast (as all are subsequent calls).