Uploaded image for project: 'Blazegraph (by SYSTAP)'
  1. Blazegraph (by SYSTAP)
  2. BLZG-2039

SPARQL QUERY and SPARQL UPDATE should be parsed before obtaining the connection

    Details

      Description

      With the change to decouple the SPARQL parser for QUERY and UPDATE from the resolution of lexical values to IVs, we no longer need to obtain a connection object before parsing a query. This will allow more overlapping of operations, especially for SPARQL UPDATE which is otherwise serialized.

      This ticket is to lift the parse step to before we obtain the connection in QueryServlet for SPARQL UPDATE and SPARQL QUERY.

        Activity

        Hide
        bryanthompson bryanthompson added a comment -

        PR: https://github.com/SYSTAP/bigdata/pull/464 addresses this for UPDATE. I am still looking at this for QUERY.

        Show
        bryanthompson bryanthompson added a comment - PR: https://github.com/SYSTAP/bigdata/pull/464 addresses this for UPDATE. I am still looking at this for QUERY.
        Hide
        bryanthompson bryanthompson added a comment -

        BigdataRDFContext.getQueryTask() gets used from the following locations:

        • QueryServlet.SparqlQueryTask.call() (SPARQL QUERY)
        • DeleteServlet.DeleteWithQueryMaterializedTask.call()
        • DeleteServlet.DeleteWithQueryStreamingTask.call()
        • UpdateServlet.UpdateWithQueryMaterializedTask.call()
        • UpdateServlet.UpdateWithQueryStreamingTask.call()

        For each of these except SPARQL QUERY, parsing the query after obtaining the connection limits concurrency and throughput.

        Show
        bryanthompson bryanthompson added a comment - BigdataRDFContext.getQueryTask() gets used from the following locations: QueryServlet.SparqlQueryTask.call() (SPARQL QUERY) DeleteServlet.DeleteWithQueryMaterializedTask.call() DeleteServlet.DeleteWithQueryStreamingTask.call() UpdateServlet.UpdateWithQueryMaterializedTask.call() UpdateServlet.UpdateWithQueryStreamingTask.call() For each of these except SPARQL QUERY, parsing the query after obtaining the connection limits concurrency and throughput.
        Hide
        bryanthompson bryanthompson added a comment -

        I've pushed a fix for the other 5 code paths identified above.

        Brad Bebee This can be merged when CI is clean.

        michaelschmidt It would be interesting to re-run the BSBM EXPLORE + UPDATE (if there is more than one client submitting updates) to see how the latency reduction looks since we now overlap the parse of the next update with the evaluation of the current update.

        Show
        bryanthompson bryanthompson added a comment - I've pushed a fix for the other 5 code paths identified above. Brad Bebee This can be merged when CI is clean. michaelschmidt It would be interesting to re-run the BSBM EXPLORE + UPDATE (if there is more than one client submitting updates) to see how the latency reduction looks since we now overlap the parse of the next update with the evaluation of the current update.

          People

          • Assignee:
            bryanthompson bryanthompson
            Reporter:
            bryanthompson bryanthompson
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: