Thanks for the clarification, Andy! Apparently, I messed things up due to an aborted, yet still running query on the local host.
The culprit for the long execution time on the remote server seems to be the SERVICE clause. Even when it points to an in-memory endpoint on the same server, execution took more than 400 sec. After loading the very same data into a named GRAPH on the same endpoint, and referencing that instead of SERVICE, execution was quick (less than 2 sec). So that seems to be the way to go. Cheers, Joachim -----Ursprüngliche Nachricht----- Von: Andy Seaborne [mailto:[email protected]] Gesendet: Mittwoch, 17. Juni 2015 16:30 An: [email protected] Betreff: Re: AW: s-query on remote endpoint On 17/06/15 15:12, Neubert, Joachim wrote: > An follow-up question: Is a > > SERVICE <http://localhost:3030/ds/query> { ... } > > clause within the query resolved as "localhost = the local machine (where > s-query is executed)" or "localhost = the remote server (referenced in the > "--service" argument to s-query)"? Where it's executed. s-query is wrapping up a query string which it to does not interpret. You can do the same thing with curl or wget - s-* happen to have some arguments to make it easier. They (it - there is only one - soh - the rest are copies as links break in distribution) are ruby scripts of a somewhat old nature. Andy > > Cheers, Joachim > > -----Ursprüngliche Nachricht----- > Von: Neubert, Joachim [mailto:[email protected]] > Gesendet: Mittwoch, 17. Juni 2015 12:00 > An: '[email protected]' > Betreff: s-query on remote endpoint > > When I execute a query with the s-query script, and -service is located on a > remote machine, I can observe that the load on the remote machine is very > low, while on the local machine fuseki consumes 100% of the cpu. The > execution takes a very long time, much more than when I execute s-query on > the remote machine. > > How is it supposed to work, and why is the local Fuseki server involved at > all? > > Cheers, Joachim >
