Mailing-List: contact dev-help@asterixdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@asterixdb.apache.org
Subject: Re: [AsterixDB] execution time metric in the HTTP API
To: dev@asterixdb.apache.org
References: <2D54DF1B-65A3-4AC9-B503-275932E11DD5@stud.ntnu.no>
 <CAEZoxMdR+ECb-jAxCC+8pfORGjY6j3X7JiPTCg82+OSNne-W0Q@mail.gmail.com>
 <7B178564-0D18-4F7E-93C1-62ABC2E3AA6F@apache.org>
 <6B0A8058-688A-4AE6-BDF0-F8BCB2410ECB@stud.ntnu.no>
 <320EF41F-BF70-4212-A061-3A79D716E773@apache.org>
From: Mike Carey <dtabass@gmail.com>
Message-ID: <f6383423-9de1-31b0-2bfd-44b94011dada@gmail.com>
Date: Mon, 5 Dec 2016 08:02:02 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0)
 Gecko/20100101 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <320EF41F-BF70-4212-A061-3A79D716E773@apache.org>
Content-Type: multipart/alternative;
 boundary="------------25106CF9805693D78EEA8100"
archived-at: Mon, 05 Dec 2016 16:03:25 -0000

--------------25106CF9805693D78EEA8100
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Agreed on this.  Also, my recollection is that there were/are three 
combos of results and synchrony that we support - sync execution with 
results returned, sync execution with just a handle returned, and async 
execution with a handle returned.  The handle can then be used to ask 
for the results in any case, when they are ready, and to ask "is it done 
yet" in the last of the three cases.  For this use case, getting stats 
back, one would want case two (sync with handle) - right?  The idea 
would be to not hear back until the work was done, but to not measure 
that final overhead of returning and swallowing the results themselves.


On 12/4/16 9:20 PM, Till Westmann wrote:
> I think that the best solution for your use-case would be to add deferred
> result delivery for the query/service API, as
> a) this API returns metrics today and
> b) it anyway is a missing feature of this API.
> I’ve filed an issue for this [1] and started work on it, but it’s not 
> quite
> done yet …
>
> One of the additional challenges is, that the query/service API 
> currently only
> supports SQL++ and not AQL. If you need AQL, we would also need to fix 
> another
> issue [2].
> Which query language do you use (and does it matter for what you are 
> trying to
> do)?
>
> Cheers,
> Till
>
> [1] https://issues.apache.org/jira/browse/ASTERIXDB-1744
> [2] https://issues.apache.org/jira/browse/ASTERIXDB-1559
>
> On 3 Dec 2016, at 6:47, Thor Martin Abrahamsen wrote:
>
>> Thanks for your suggestions, Pouria and Till.
>>
>> Using the «mode=asynchronous-deferred» returned only the handle, just 
>> as I wanted. But I am not getting any metrics with the response. Just 
>> the handle. The same goes for the request without the «mode» 
>> parameter: I only get the results, not any metrics. Is there a way to 
>> get metrics with the API response? Or is it possible to use 
>> «mode=asynchronous-deferred» in the web interface?
>>
>> The asterixClient worked perfectly, but the execution time returned 
>> is calculated in the client, not by AsterixDB (please correct me if 
>> I’m wrong Pouria). Ideally I would like the isolated AsterixDB 
>> execution time, and don’t consider network delay or client 
>> performance. I might try running the client on the same node as the 
>> CC :)
>>
>>
>>
>> Best regards
>> Thor Martin Abrahamsen
>> Student @ NTNU
>> Tlf. +47 470 78 713
>>
>> 2. des. 2016 kl. 20.45 skrev Till Westmann 
>> <tillw@apache.org<mailto:tillw@apache.org>>:
>>
>> Hi,
>>
>> an alternative to using the client that Pouria suggested would be to add
>> "mode=asynchronous-deferred" as an HTTP parameter when talking to the 
>> API. In
>> that case the query should be evaluated completely and an HTTP 
>> response should
>> come back - however without the result. Instead the response should 
>> contain a
>> handle where you could pick up the query result (which you could 
>> choose not to
>> do).
>> I'm using "should" a lot, as I haven't used this feature for a while, 
>> and so my
>> recollection of what it does might be buggy or outdated.
>>
>> Cheers,
>> Till
>>
>> On 2 Dec 2016, at 11:16, Pouria Pirzadeh wrote:
>>
>> You may find the following client useful.
>> It works against the HTTP, runs query workload for one or more 
>> iterations
>> and dumps the response time per query/iteration in a stats file.
>>
>> https://github.com/pouriapirz/asterixClient
>>
>> Pouria
>>
>> On Fri, Dec 2, 2016 at 10:45 AM, Thor Martin Abrahamsen 
>> <thorma@stud.ntnu.no
>> wrote:
>>
>> Hi,
>>
>> Is it possible to get the execution time metric in the HTTP API?
>>
>> I’m running some queries and are interested in the execution time. In 
>> the
>> web interface the duration is printed below the results, but I want the
>> queries to execute without printing the results. Either in the web
>> interface, or through the API. The specific query is iterating through a
>> dataset and applying a library function on each record.
>>
>> I am working on a student project together with Heri.
>>
>>
>> Mvh.
>> Thor Martin Abrahamsen
>> Student @ NTNU
>> Tlf. +47 470 78 713


--------------25106CF9805693D78EEA8100--