Elapsed query time?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Elapsed query time?

Stephen Smith
Is it possible to get the search query time from the server to enable
Google-style "Searched 45,000 documents in 0.03 seconds"-type
reporting for logging or to show to end users?
Reply | Threaded
Open this post in threaded view
|

Re: Elapsed query time?

kimchy
Administrator
It can be added, but you can also add it around the search request, no?

On Thu, Mar 4, 2010 at 5:32 PM, Stephen Smith <[hidden email]> wrote:
Is it possible to get the search query time from the server to enable
Google-style "Searched 45,000 documents in 0.03 seconds"-type
reporting for logging or to show to end users?

Reply | Threaded
Open this post in threaded view
|

Re: Elapsed query time?

Stephen Smith
I could, but that number would reflect HTTP transport time that might
vary independently of the time ElasticSearch takes to complete an
operation. If a query takes 500ms to complete, it might be helpful (at
least for debugging) for the app to know how much of the time is spent
in ES.

On Mar 4, 11:00 am, Shay Banon <[hidden email]> wrote:
> It can be added, but you can also add it around the search request, no?
>
> On Thu, Mar 4, 2010 at 5:32 PM, Stephen Smith <[hidden email]>wrote:
>
> > Is it possible to get the search query time from the server to enable
> > Google-style "Searched 45,000 documents in 0.03 seconds"-type
> > reporting for logging or to show to end users?
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Elapsed query time?

kimchy
Administrator
Agreed. This, by the way, does not apply only to the search API but to all APIs. I just hate taking the system time when I can avoid it, so maybe it will be optional?

-shay.banon

On Thu, Mar 4, 2010 at 6:59 PM, Stephen Smith <[hidden email]> wrote:
I could, but that number would reflect HTTP transport time that might
vary independently of the time ElasticSearch takes to complete an
operation. If a query takes 500ms to complete, it might be helpful (at
least for debugging) for the app to know how much of the time is spent
in ES.

On Mar 4, 11:00 am, Shay Banon <[hidden email]> wrote:
> It can be added, but you can also add it around the search request, no?
>
> On Thu, Mar 4, 2010 at 5:32 PM, Stephen Smith <[hidden email]>wrote:
>
> > Is it possible to get the search query time from the server to enable
> > Google-style "Searched 45,000 documents in 0.03 seconds"-type
> > reporting for logging or to show to end users?
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Elapsed query time?

Sergio Bossa
On Thu, Mar 4, 2010 at 6:02 PM, Shay Banon <[hidden email]> wrote:

> Agreed. This, by the way, does not apply only to the search API but to all
> APIs. I just hate taking the system time when I can avoid it, so maybe it
> will be optional?

What about providing some kind of interceptor API on top of your HTTP module?

--
Sergio Bossa
http://www.linkedin.com/in/sergiob
Reply | Threaded
Open this post in threaded view
|

Re: Elapsed query time?

kimchy
Administrator
Yes, interceptor level APIs is the way to go. In terms of implementation though, there is the HTTP module and there is the Transport module, in this case, you would want to do it on the transport level so other APIs (the HTTP among them, but Java API and so on) will get it for free.

-shay.banon

On Thu, Mar 4, 2010 at 7:07 PM, Sergio Bossa <[hidden email]> wrote:
On Thu, Mar 4, 2010 at 6:02 PM, Shay Banon <[hidden email]> wrote:

> Agreed. This, by the way, does not apply only to the search API but to all
> APIs. I just hate taking the system time when I can avoid it, so maybe it
> will be optional?

What about providing some kind of interceptor API on top of your HTTP module?

--
Sergio Bossa
http://www.linkedin.com/in/sergiob

Reply | Threaded
Open this post in threaded view
|

Re: Elapsed query time?

Sergio Bossa
On Thu, Mar 4, 2010 at 6:25 PM, Shay Banon <[hidden email]> wrote:

> Yes, interceptor level APIs is the way to go. In terms of implementation
> though, there is the HTTP module and there is the Transport module, in this
> case, you would want to do it on the transport level

So does the transport level get fired even for *local* calls (that is,
requests answered by the node itself)?

--
Sergio Bossa
http://www.linkedin.com/in/sergiob
Reply | Threaded
Open this post in threaded view
|

Re: Elapsed query time?

kimchy
Administrator
Yes, they do. Its not really the transport module, more the Transport based APIs, which have a single point entry for each API regardless if it ends up being called locally or remotely.

-shay.banon

On Thu, Mar 4, 2010 at 7:29 PM, Sergio Bossa <[hidden email]> wrote:
On Thu, Mar 4, 2010 at 6:25 PM, Shay Banon <[hidden email]> wrote:

> Yes, interceptor level APIs is the way to go. In terms of implementation
> though, there is the HTTP module and there is the Transport module, in this
> case, you would want to do it on the transport level

So does the transport level get fired even for *local* calls (that is,
requests answered by the node itself)?

--

Reply | Threaded
Open this post in threaded view
|

Re: Elapsed query time?

kimchy
Administrator
One more note, because of the async nature of elasticsearch (completely async tcp for example), its not simple to write an interceptor. The "before" will probably need to create a Context, which will be passed to the "after".

-shay.banon

On Thu, Mar 4, 2010 at 7:30 PM, Shay Banon <[hidden email]> wrote:
Yes, they do. Its not really the transport module, more the Transport based APIs, which have a single point entry for each API regardless if it ends up being called locally or remotely.

-shay.banon


On Thu, Mar 4, 2010 at 7:29 PM, Sergio Bossa <[hidden email]> wrote:
On Thu, Mar 4, 2010 at 6:25 PM, Shay Banon <[hidden email]> wrote:

> Yes, interceptor level APIs is the way to go. In terms of implementation
> though, there is the HTTP module and there is the Transport module, in this
> case, you would want to do it on the transport level

So does the transport level get fired even for *local* calls (that is,
requests answered by the node itself)?

--


Reply | Threaded
Open this post in threaded view
|

Re: Elapsed query time?

Sergio Bossa
On Thu, Mar 4, 2010 at 6:36 PM, Shay Banon <[hidden email]> wrote:

> One more note, because of the async nature of elasticsearch (completely
> async tcp for example),

Is it async meaning it doesn't wait for the indexing response? Or does
it rather wait by using some kind of continuation?

--
Sergio Bossa
http://www.linkedin.com/in/sergiob
Reply | Threaded
Open this post in threaded view
|

Re: Elapsed query time?

Lukáš Vlček
Hi,

I think that what Shay meant was that in ES Java API you get ActionFuture as a response when submitting a request. It is based on Java Future API (http://java.sun.com/javase/6/docs/api/java/util/concurrent/Future.html).

See

Lukas

On Thu, Mar 4, 2010 at 6:45 PM, Sergio Bossa <[hidden email]> wrote:
On Thu, Mar 4, 2010 at 6:36 PM, Shay Banon <[hidden email]> wrote:

> One more note, because of the async nature of elasticsearch (completely
> async tcp for example),

Is it async meaning it doesn't wait for the indexing response? Or does
it rather wait by using some kind of continuation?

--

Reply | Threaded
Open this post in threaded view
|

Re: Elapsed query time?

kimchy
Administrator
In reply to this post by Sergio Bossa
Yes, its basically continuation. All of elasticsearch is built on top to not blocking threads on network.

-shay.banon

On Thu, Mar 4, 2010 at 7:45 PM, Sergio Bossa <[hidden email]> wrote:
On Thu, Mar 4, 2010 at 6:36 PM, Shay Banon <[hidden email]> wrote:

> One more note, because of the async nature of elasticsearch (completely
> async tcp for example),

Is it async meaning it doesn't wait for the indexing response? Or does
it rather wait by using some kind of continuation?

--