我们有一些python脚本来执行sparql查询和"更新" (插入/删除)。以下是大部分相关代码(我认为):
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
我们对execute_query的所有调用都非常快,不到1秒即可完成。但是,对execute_update的任何调用都需要很长时间(第16次)。第一个之后的每次通话都在不到1秒的时间内完成。我们正在运行芝麻版本2.7.12(我们认为从芝麻版本2.7.3升级可能有所帮助,但它没有多少)。我们只有2或3千三倍。这一切都是从CGI脚本运行的,所以我们真的只是让python会话保持活跃状态来进行更新调用(无论如何不是那个工作台的工作?)。关于第一次调用update_endpoint需要花费多长时间的任何想法?其他人有同样的问题吗?任何建议的决议?
谢谢!
修改 我遵循了RobV的建议,但我仍然遇到同样的问题。来自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
第一次调用/ statements端点时可以看到很大的差距。
答案 0 :(得分:3)
当我们创建存储库时,我们将其创建为“In Memory Store”存储库。我创建了一个“Native Java Store”类型的新存储库,现在我的第一个调用很快(因为所有调用都是后续调用)。
答案 1 :(得分:2)
Sesame工作台和服务器是在Web应用程序容器中的不同应用程序上下文中运行的两个不同的应用程序。
您的CGI代码直接将查询定向到Sesame服务器,但会将更新定向到Sesame工作台。
Sesame工作台实际上只是Sesame服务器的UI,实际上是将您的请求代理到底层的Sesame服务器上。第一次进行更新时,Workbench必须建立与服务器的连接,我认为这涉及向Sesame服务器发出各种额外的元数据请求。在此之后,工作台缓存连接,这就是后续更新运行速度非常快的原因。
可以直接针对Sesame服务器进行更新,方法是将更新端点更改为使用Sesame服务器/statements
端点,而不是Sesame HTTP Protocol documentation中详细说明的那样。
update_endpoint = "http://%s:8080/openrdf-sesame/repositories/%s/statements" % (server,repo)
直接针对Sesame服务器,你应该消除第一次更新的长时间延迟。