Virtuoso Sparql Query Editor slower than ISQL

[albeiroep]

Hello.

I'm testing the Virtuoso Sparql Query Editor and i realize that his performance takes much more time compared with the execution of my query directly on ISQL.

Do you have some idea about why does this happen?

[TallTed]

There are several possibilities.

To start analysis, it would help to have the full query that you're executing in iSQL, along with the fully parameterized link to the /sparql results page (whether it's public or not), so we can see whether there are any differences you may not have realized are present.

It is usually also helpful to confirm the version of the Virtuoso binary (output of virtuoso-t -? or virtuoso-iodbc-t -? is best), and of all installed VADs.

Output of status();, executed in iSQL, is also likely to be helpful.

[albeiroep]

Hello TallTed. I'm not using a parameterized link. I'm using the Virtuoso Sparql Query Editor tool. My Virtuoso binary version is 7.2.4.2.3217-pthreads according to virtuoso-t -?.

The vad_list_packages() result :

conductor build date  : 2017-06-15 
conductor version : 1.00.8759 

Finally, the status command result for ISQL

OpenLink Virtuoso  Server
Version 07.20.3217-pthreads for Linux as of Jun 15 2017 
Started on: 2019-09-25 16:55 GMT+0

Database Status:
  File size 0, 7245312 pages, 2902868 free.
  2040000 buffers, 77633 used, 34 dirty 2 wired down, repl age 0 0 w. io 35 w/crsr.
  Disk Usage: 78225 reads avg 0 msec, 0% r 0% w last  112 s, 5794 writes flush          0 MB,
    364 read ahead, batch = 206.  Autocompact 0 in 0 out, 0% saved.
Gate:  250 2nd in reads, 0 gate write waits, 0 in while read 0 busy scrap. 
Log = /usr/local/virtuoso-opensource/var/lib/virtuoso/db/virtuoso.trx, 7637 bytes
4342071 pages have been changed since last backup (in checkpoint state)
Current backup timestamp: 0x0000-0x00-0x00
Last backup date: unknown
Clients: 2 connects, max 2 concurrent
RPC: 33 calls, 2 pending, 2 max until now, 0 queued, 5 burst reads (15%), 0 second 17M large, 29M max
Checkpoint Remap 0 pages, 0 mapped back. 2 s atomic time.
    DB master 7245312 total 2902868 free 0 remap 0 mapped back
   temp  768 total 763 free

Lock Status: 0 deadlocks of which 0 2r1w, 16 waits,
   Currently 8 threads running 0 threads waiting 0 threads in vdb.
Pending:

Client 1111:1:  Account: dba, 2098 bytes in, 26866 bytes out, 1 stmts.
PID: 72, OS: unix, Application: unknown, IP#: 127.0.0.1
Transaction status: PENDING, 1 threads.
Locks: 

Client 1111:2:  Account: dba, 200 bytes in, 286 bytes out, 1 stmts.
PID: 91, OS: unix, Application: unknown, IP#: 127.0.0.1
Transaction status: PENDING, 1 threads.
Locks: 

Running Statements:
 Time (msec) Text
         173 status()
        1848 SPARQL SELECT ?g (COUNT(*) AS ?nb) WHERE { GRAPH ?g { ?subject ?verb ?complement

Hash indexes    `

and the Virtuoso Query Editor execution results for the status command :

Status Virtuoso Endpoint

OpenLink Virtuoso  Server
Version 07.20.3217-pthreads for Linux as of Jun 15 2017 
Started on: 2019-09-25 16:55 GMT+0

Database Status:
  File size 0, 7245312 pages, 2902868 free.
  2040000 buffers, 77633 used, 34 dirty 1 wired down, repl age 0 0 w. io 34 w/crsr.
  Disk Usage: 78225 reads avg 0 msec, 0% r 0% w last  8 s, 5794 writes flush          0 MB,
    364 read ahead, batch = 206.  Autocompact 0 in 0 out, 0% saved.
Gate:  250 2nd in reads, 0 gate write waits, 0 in while read 0 busy scrap. 
Log = /usr/local/virtuoso-opensource/var/lib/virtuoso/db/virtuoso.trx, 7637 bytes
4342071 pages have been changed since last backup (in checkpoint state)
Current backup timestamp: 0x0000-0x00-0x00
Last backup date: unknown
Clients: 1 connects, max 1 concurrent
RPC: 26 calls, 1 pending, 1 max until now, 0 queued, 2 burst reads (7%), 0 second 17M large, 29M max
Checkpoint Remap 0 pages, 0 mapped back. 2 s atomic time.
    DB master 7245312 total 2902868 free 0 remap 0 mapped back
   temp  768 total 763 free

Lock Status: 0 deadlocks of which 0 2r1w, 16 waits,
   Currently 8 threads running 0 threads waiting 0 threads in vdb.
Pending:

Client 1111:1:  Account: dba, 1654 bytes in, 22457 bytes out, 1 stmts.
PID: 72, OS: unix, Application: unknown, IP#: 127.0.0.1
Transaction status: PENDING, 1 threads.
Locks: 

Running Statements:
 Time (msec) Text
         172 status()

Hash indexes

Thank you in advance

[TallTed]

When you see the results of a SPARQL query you've executed through the /sparql Query Editor page, your browser has a link in the location box.

This is a fully parameterized query link, which can be shared with others, as with this simple query against DBpedia --

http://dbpedia.org/sparql?default-graph-uri=http%3A%2F%2Fdbpedia.org&query=select+distinct+%3FConcept+where+%7B%5B%5D+a+%3FConcept%7D+LIMIT+5&format=text%2Fhtml&CXML_redir_for_subjs=121&CXML_redir_for_hrefs=&timeout=30000&debug=on&run=+Run+Query+

If you change the &query= to &qtxt=, it becomes a link to a populated query form --

http://dbpedia.org/sparql?default-graph-uri=http%3A%2F%2Fdbpedia.org&qtxt=select+distinct+%3FConcept+where+%7B%5B%5D+a+%3FConcept%7D+LIMIT+5&format=text%2Fhtml&CXML_redir_for_subjs=121&CXML_redir_for_hrefs=&timeout=30000&debug=on&run=+Run+Query+

I want to see that URL. It's OK if your endpoint is behind a firewall or otherwise inaccessible to me.

I also want to see the SQL query you're executing, from the initial SPARQL keyword through the terminating ;.

[albeiroep]

Hello @TallTed.

The query i'm executing is :

SELECT ?g (COUNT(*) AS ?nb)
WHERE {
  GRAPH ?g { ?subject ?verb ?complement . }
}
GROUP BY ?g
ORDER BY DESC(?nb)

And the corresponding fully parameterized query link :

http://localhost:8890/sparql?default-graph-uri=&query=SELECT+%3Fg+%28COUNT%28*%29+AS+%3Fnb%29%0D%0AWHERE+%7B%0D%0A++GRAPH+%3Fg+%7B+%3Fsubject+%3Fverb+%3Fcomplement+.+%7D%0D%0A%7D%0D%0AGROUP+BY+%3Fg%0D%0AORDER+BY+DESC%28%3Fnb%29&format=text%2Fhtml&timeout=0&debug=on