Re: [Bigdata-developers] trivial ASK takes over 5s

[Bryan T. <br...@sy...>]

You might try the EST_CARD interface for a lightweight request.  It will
return a range count without the overhead of parsing a SPARQL request.

----
Bryan Thompson
Chief Scientist & Founder
Blazegraph
e: br...@bl...
w: http://blazegraph.com

Blazegraph products help to solve the Graph Cache Thrash to achieve large
scale processing for graph and predictive analytics.  Blazegraph is the
creator of the industry’s first GPU-accelerated high-performance database
for large graphs, has been named as one of the “10 Companies and
Technologies to Watch in 2016” <http://insideanalysis.com/2016/01/20535/>.

Blazegraph Database <https://www.blazegraph.com/> is our ultra-high
performance graph database that supports both RDF/SPARQL and
Tinkerpop/Blueprints APIs.   Blazegraph GPU
<https://www.blazegraph.com/product/gpu-accelerated/> andBlazegraph DAS
<https://www.blazegraph.com/product/gpu-accelerated/>L are disruptive new
technologies that use GPUs to enable extreme scaling that is thousands of
times faster and 40 times more affordable than CPU-based solutions.

CONFIDENTIALITY NOTICE:  This email and its contents and attachments are
for the sole use of the intended recipient(s) and are confidential or
proprietary to SYSTAP, LLC DBA Blazegraph.  Any unauthorized review, use,
disclosure, dissemination or copying of this email or its contents or
attachments is prohibited. If you have received this communication in
error, please notify the sender by reply email and permanently delete all
copies of the email and its contents and attachments.

On Thu, Mar 17, 2016 at 5:51 PM, Jeremy J Carroll <jj...@sy...> wrote:

>
> As part of our health check that ensures we know when our system go down,
> we send the following query to all our blazegraph instances every minute:
>
> ASK
> FROM <http://does-not-exist.example.org/an/empty/named/graph>
> FROM NAMED <http://does-not-exist.example.org/an/empty/named/graph>
>
> WHERE {
>
> }
>
>
> Normally this is very quick!
>
> However, during a period of heavy write activity using INSERT-by-POST
> commands that seem to be taking around 30s (this is from logs one level
> out, so there is room for doubt), we were seeing these queries occasionally
> take over 5s (the trivial ASK).
>
> Is this expected?
>
> My general belief was that writes and concurrent reads did not strongly
> conflict in blazegraph.
>
>
> Jeremy
>
>
>
>
> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
> _______________________________________________
> Bigdata-developers mailing list
> Big...@li...
> https://lists.sourceforge.net/lists/listinfo/bigdata-developers
>