Thank you for your advices. Currently we have 4 Solr nodes, with 12Gb memory (heap) ; the collections are replicated (4 shards, 1 replica). This query mostly returns a QTime=4 and it takes around 20ms on the client side to get the result.
We have to handle around 200 simultaneous connections. Currently I do not use a load balancing between our 4 nodes, I only send query to one of the node. I will test to balance between the 4 nodes to see what happens. Thank you. Regards, 2016-01-19 15:08 GMT+01:00 Shawn Heisey <apa...@elyograg.org>: > On 1/19/2016 3:43 AM, Damien Picard wrote: > > I'm currently testing Solr query execution performance (over http and > > SolrJ), and, using HTTP with JMeter, I see that the response time > increases > > with the number of concurrent request (100 simultaneous request in my > case). > > > > To understand where Solr takes more time, I use the debug=timing > parameter. > > And I see this kind of response : > > > > <?xml version="1.0" encoding="UTF-8"?> > > <response> > > > > <lst name="responseHeader"> > > <int name="status">0</int> > > <int name="QTime">3003</int> > > <lst name="params"> > > <str name="q">uuid:FA2C9342381E3969E04456C8B4C639A9</str> > > <str name="debug">timing</str> > > <str name="indent">true</str> > > <str name="wt">xml</str> > > </lst> > > </lst> > > <result name="response" numFound="1" start="0" maxScore="15.705477"> > > <doc> > > <bool name="bc_repe_pro">false</bool> > > <str name="type_personne">P</str> > > <str name="numero_dossier_client">30000224149</str> > > <str name="uuid">FA2C9342381E3969E04456C8B4C639A9</str> > > <str name="cle_recherche">FA2C9342381E3969E04456C8B4C639A9_P</str> > > <long name="_version_">1518391139884859416</long></doc> > > </result> > > <lst name="debug"> > > <lst name="timing"> > > <double name="time">0.0</double> > > <lst name="prepare"> > > <double name="time">0.0</double> > > <lst name="query"> > > <double name="time">0.0</double> > > </lst> > > <lst name="facet"> > > <double name="time">0.0</double> > > </lst> > > <lst name="mlt"> > > <double name="time">0.0</double> > > </lst> > > <lst name="highlight"> > > <double name="time">0.0</double> > > </lst> > > <lst name="stats"> > > <double name="time">0.0</double> > > </lst> > > <lst name="debug"> > > <double name="time">0.0</double> > > </lst> > > </lst> > > <lst name="process"> > > <double name="time">0.0</double> > > <lst name="query"> > > <double name="time">0.0</double> > > </lst> > > <lst name="facet"> > > <double name="time">0.0</double> > > </lst> > > <lst name="mlt"> > > <double name="time">0.0</double> > > </lst> > > <lst name="highlight"> > > <double name="time">0.0</double> > > </lst> > > <lst name="stats"> > > <double name="time">0.0</double> > > </lst> > > <lst name="debug"> > > <double name="time">0.0</double> > > </lst> > > </lst> > > </lst> > > </lst> > > </response> > > QTime is not part of the debug. It is included on all results, whether > debug is turned on or not. I am not sure why all your debug information > says zero. Usually the total of all the debugs does not add up to > QTime, but this is an extreme imbalance. > > QTime is the amount of time spent gathering result information -- the > internal Lucene identifiers of the documents counted for numFound. The > response does not indicate the amount of time that was spent retrieving > the actual search results from the stored fields and sending those > results to the client, but with only one document found, those things > would be extremely fast. > > Running 100 queries concurrently is usually enough to topple *any* > single Solr server unless the index is very small. If you need to scale > up this far, you will need multiple replicas of your index. > > If you are not running a performance benchmark, how long does a single > query like this take? If this kind of QTime is normal even when not > hammering the server, then you probably don't have enough memory. > > Thanks, > Shawn > > -- Damien Picard Expert GWT <http://www.editions-eni.fr/livres/gwt-google-web-toolkit-developpez-des-applications-internet-riches-ria-en-java/.97a1a26e7d5be94763fc45ac2a1e961a.html> Mob : 06 11 51 47 78
