Thanks,
It is clear that a test is strongly dependent of your data / hardware etc. My
question was a little bit more general because I've read on some article in the
internet and in book "Apache Solr Enterprise Search server" that virtualization
should be avoided. Since this was a general suggestion, I was curious if there
are some data to back up this suggestion. For what I know, modern hardware and
virtualization tool are really good, and VM usually does have negligible loss
of performances than bare metal.
For load balancer it is true that server client API in SolrJ handle everything,
but for .NET I do not remember that a client with the same functionalities
exists. Moreover some customer prefer using direct access with HTTP calls.
Is there a list of all client libraries, other than Solrj for different
technologies that can do an internal routing and round robin? (Ex: .NET,
Node.JS, etc)
Thanks a lot.
--
Gian Maria Ricci
Cell: +39 320 0136949
-----Original Message-----
From: Jack Krupansky [mailto:jack.krupan...@gmail.com]
Sent: giovedì 21 gennaio 2016 16:22
To: solr-user@lucene.apache.org
Subject: Re: Couple of question about Virtualization and Load Balancer
Official numbers? There are none. If for no other reason than that performance
is completely dependent on your specific hardware and your specific data and
your specific data model. The standard recommendation is that you should do a
proof of concept implementation with a reas onable subset of your data and
judge for yourself whether the throughput and latency are sufficient for your
own specific requirements. Not everyone has extreme throughput and latency
requirements. If your requirements are extreme then virtualization will likely
not to work out for you, but if your requirements are reasonably mild and you
adequately provision your cluster with enough shards and enough replicas, then
virtualization may actually work out well for you. Either way, adequately
provisioning the cluster (not overloading individual nodes with either too many
documents or too many requests) is always essential unless you are working with
a very small collection of data with a very light load.
The standard recommendation is to avoid the use of a load balancer between the
app and Solr - since the server client API in SolrJ automatically does smart
routing and round-robin load balancing:
https://lucene.apache.org/solr/5_4_0/solr-solrj/org/apache/solr/client/solrj/impl/CloudSolrClient.h
tml
https://lucene.apache.org/solr/5_4_0/solr-solrj/org/apache/solr/client/solrj/impl/CloudSolrServer.html
You may want a load balancer in front of multiple instances of your app, but
that's not a question or issue for Solr. The only issue there is assuring that
you have enough Solr shards and replicas to handle the aggregate request load.
-- Jack Krupansky
On Thu, Jan 21, 2016 at 6:37 AM, Gian Maria Ricci - aka Alkampfer <
alkamp...@nablasoft.com> wrote:
> Hi,
>
>
>
> I’ve a couple of quick question about production setup.
>
>
>
> The first one is about virtualization, I’d like to know if there are
> any official test on loss of performance in virtualization
> environment. I think that the loss of performance is negligible, and
> quick question on test infrastructure is confirming this, but I’d like
> to know if there is some official numbers on this.
>
>
>
> The second question is about Load Balancer: any clue on how to
> automatically
change the configuration on the load balancer if some of the
> node goes down? I’m looking to advices on what to monitor, the
> simplest solution could be issuing some test query and verify if the
> node is able to answer, but it would be nice to know if there are some
> standard metrics to monitor to proactively alert. (Es. Heap size
> almost full, so it would be probably better to remove the node from
> the balancer and alert a human to have a look at the status of the node).
>
>
>
> Many thanks.
>
>
>
> --
> Gian Maria Ricci
> Cell: +39 320 0136949
>
> [image:
> https://ci5.googleusercontent.com/proxy/5oNMOYAeFXZ_LDKanNfoLRHC37mAZk
> VVhkPN7QxMdA0K5JW2m0bm8azJe7oWZMNt8fKHNX1bzrUTd-kIyE40CmwT2Mlf8OI=s0-d
> -e1-ft#http://www.codewrecks.com/files/signature/mvp.png]
> <http://mvp.microsoft.com/en-us/mvp/Gian%20Maria%20Ricci-4025635> [image:
> https://ci3.googleusercontent.com/proxy/f-unQbmk6NtkHFspO5Y6x4jlIf_xrm
> GLUT3fU9y_7VUHSFUjLs7aUIMdZQYTh3eWIA0sBnvNX3WGXCU59chK
XLuAHi2ArWdAcBclKA=s0-d-e1-ft#http://www.codewrecks.com/files/signature/linkedin.jpg]
> <http://www.linkedin.com/in/gianmariaricci> [image:
> https://ci3.googleusercontent.com/proxy/gjapMzu3KEakBQUstx_-cN7gHJ_Gpc
> IZNEPjCzOYMrPl-r1DViPE378qNAQyEWbXMTj6mcduIAGaApe9qHG1KN_hyFxQAIkdNSVT
> =s0-d-e1-ft#http://www.codewrecks.com/files/signature/twitter.jpg]
> <https://twitter.com/alkampfer> [image:
> https://ci5.googleusercontent.com/proxy/iuDOD2sdaxRDvTwS8MO7-CcXchpNJX
> 96uaWuvagoVLcjpAPsJi88XeOonE4vHT6udVimo7yL9ZtdrYueEfH7jXnudmi_Vvw=s0-d
> -e1-ft#http://www.codewrecks.com/files/signature/rss.jpg]
> <http://feeds.feedburner.com/AlkampferEng> [image:
> https://ci6.googleusercontent.com/proxy/EBJjfkBzcsSlAzlyR88y86YXcwaKfn
> 3x7ydAObL1vtjJYclQr_l5TvrFx4PQ5qLNYW3yp7Ig66DJ-0tPJCDbDmYAFcamPQehwg=s
> 0-d-e1-ft#http://www.codewrecks.com/files/signature/skype.jpg]
>
>
>
