javascript es client - should es clients be pooled?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

javascript es client - should es clients be pooled?

Phil Swenson-2
I'm writing a node/es app using the es javascript api....

Is there any reason to use pooling for all the javascript clients?  Or should I just use one client for the app?

Thanks,
phil

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/a44a6a6e-8763-44f5-9e2d-8ea52dcf0345%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: javascript es client - should es clients be pooled?

Phil Swenson-2
no answer, so let me ask a different way.  how are most of the es javascript client apps managing the instance of the client?

do you have one es client per app (singleton) that all requests go through?  Do you create and destroy clients for every request?  Do you use a es client pool using something like https://github.com/coopernurse/node-pool ?

Thanks for any comments!

phil

On Wed, Dec 24, 2014 at 10:34 AM, Phil Swenson <[hidden email]> wrote:
I'm writing a node/es app using the es javascript api....

Is there any reason to use pooling for all the javascript clients?  Or should I just use one client for the app?

Thanks,
phil

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/a44a6a6e-8763-44f5-9e2d-8ea52dcf0345%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAGenvhVYD-fRkrVx5j0XR_xNYM2eSFFFxh2TxJnEar-HEWVfSg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: javascript es client - should es clients be pooled?

Jack Park-2
On my platform, there is one and only one es client, through which all requests go. It seems to work well, though "well" is defined as having just a few people using it at one time. We plan to start stress testing the system soon.

Cheers
Jack

On Fri, Dec 26, 2014 at 9:55 AM, phil swenson <[hidden email]> wrote:
no answer, so let me ask a different way.  how are most of the es javascript client apps managing the instance of the client?

do you have one es client per app (singleton) that all requests go through?  Do you create and destroy clients for every request?  Do you use a es client pool using something like https://github.com/coopernurse/node-pool ?

Thanks for any comments!

phil

On Wed, Dec 24, 2014 at 10:34 AM, Phil Swenson <[hidden email]> wrote:
I'm writing a node/es app using the es javascript api....

Is there any reason to use pooling for all the javascript clients?  Or should I just use one client for the app?

Thanks,
phil

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/a44a6a6e-8763-44f5-9e2d-8ea52dcf0345%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAGenvhVYD-fRkrVx5j0XR_xNYM2eSFFFxh2TxJnEar-HEWVfSg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAH6s0fyEhW5b-BXCYViAb7Ej4XNC5shjjVE_kYfPKOcx6H-dng%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: javascript es client - should es clients be pooled?

Phil Swenson-2
thanks jack, let me know how your testing goes!

On Fri, Dec 26, 2014 at 11:57 AM, Jack Park <[hidden email]> wrote:
On my platform, there is one and only one es client, through which all requests go. It seems to work well, though "well" is defined as having just a few people using it at one time. We plan to start stress testing the system soon.

Cheers
Jack

On Fri, Dec 26, 2014 at 9:55 AM, phil swenson <[hidden email]> wrote:
no answer, so let me ask a different way.  how are most of the es javascript client apps managing the instance of the client?

do you have one es client per app (singleton) that all requests go through?  Do you create and destroy clients for every request?  Do you use a es client pool using something like https://github.com/coopernurse/node-pool ?

Thanks for any comments!

phil

On Wed, Dec 24, 2014 at 10:34 AM, Phil Swenson <[hidden email]> wrote:
I'm writing a node/es app using the es javascript api....

Is there any reason to use pooling for all the javascript clients?  Or should I just use one client for the app?

Thanks,
phil

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/a44a6a6e-8763-44f5-9e2d-8ea52dcf0345%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAGenvhVYD-fRkrVx5j0XR_xNYM2eSFFFxh2TxJnEar-HEWVfSg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAH6s0fyEhW5b-BXCYViAb7Ej4XNC5shjjVE_kYfPKOcx6H-dng%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAGenvhX4Gk80WG%3D33QzTzpDL-PDQ4eOm4JZZkToG1sXCY_bVfw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.