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?
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 stephen.smith@gmail.comwrote:
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?
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 shay.ba...@elasticsearch.com 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 stephen.sm...@gmail.comwrote:
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?
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 stephen.smith@gmail.comwrote:
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 shay.ba...@elasticsearch.com 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 <stephen.sm...@gmail.com
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?
On Thu, Mar 4, 2010 at 6:02 PM, Shay Banon shay.banon@elasticsearch.com 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
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 sergio.bossa@gmail.com wrote:
On Thu, Mar 4, 2010 at 6:02 PM, Shay Banon shay.banon@elasticsearch.com
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
On Thu, Mar 4, 2010 at 6:25 PM, Shay Banon shay.banon@elasticsearch.com 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
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 sergio.bossa@gmail.com wrote:
On Thu, Mar 4, 2010 at 6:25 PM, Shay Banon shay.banon@elasticsearch.com
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 levelSo 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
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 shay.banon@elasticsearch.comwrote:
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 sergio.bossa@gmail.comwrote:
On Thu, Mar 4, 2010 at 6:25 PM, Shay Banon shay.banon@elasticsearch.com
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 levelSo 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
On Thu, Mar 4, 2010 at 6:36 PM, Shay Banon shay.banon@elasticsearch.com 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
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 (
Future (Java Platform SE 6)).
See
org.elasticsearch.action.Actionhttp://github.com/elasticsearch/elasticsearch/blob/b3337c312765e51cec7bde5883bbc0a08f56fb65/modules/elasticsearch/src/main/java/org/elasticsearch/action/Action.java
org.elasticsearch.action.ActionFuturehttp://github.com/elasticsearch/elasticsearch/blob/b3337c312765e51cec7bde5883bbc0a08f56fb65/modules/elasticsearch/src/main/java/org/elasticsearch/action/ActionFuture.java
Lukas
On Thu, Mar 4, 2010 at 6:45 PM, Sergio Bossa sergio.bossa@gmail.com wrote:
On Thu, Mar 4, 2010 at 6:36 PM, Shay Banon shay.banon@elasticsearch.com
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
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 sergio.bossa@gmail.com wrote:
On Thu, Mar 4, 2010 at 6:36 PM, Shay Banon shay.banon@elasticsearch.com
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