You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by Ma...@rzf.fin-nrw.de on 2010/10/22 14:53:25 UTC

solr performance

last week we put our solr in production. it was a very smooth start. solr really works great and without any problems so far. 
its a huge improvement over our old intranet search 

i wonder however whether we can increase the search performance of our solr installation, just to make the search experience even better.

i know that performance is depended on many different things and parameters so a general answer is hard to make.

here are some figures:

- at the moment we have a bout 20.000 search queries a day.
- median query time is about 400ms
- ca. 80% are running under 500ms
- ca. 90% are running under 1s, 
- ca. 10% over 1s, 3% over 2s, 
- there are even some queries which lasts way to looong, over 6s and up to 18s
there are even simple queries for one word which last that long.
maybe there is one special thing to mention. we do have a kind of user-filter with each query,
these parameters differs for each usergroup, so i think at least one of the caches won't work very well, because even if the query (foobar) is the same, fq and bq can (and will) differ from user to user.

fq=__intern:0+OR+__intern:344 together with a boost query bq=__lokal:0^6+OR+__lokal:344^2

our query looks like:

INFO: [core] webapp=/solr path=/select params={spellcheck=true&facet=on&facet.limit=500&initSearch=1&hl=on&version=1.2&bq=__lokal:0^6+OR+__lokal:344^2&fl=score,+id,+title,+visiblePath,+__doctype,+_erstelldatum,+_dienststelle,+_dokumententyp,+__source,+__intern,+objClass,+jurislinkUrl,+destinationUrl,+_aktenzeichen,+_stelle,+_zielgruppen,+_stichwort,+_kurzbeschreibung,+_autor,+_hauptthema,+_unterthema&facet.field=__source&facet.field=__dst&facet.field=__cyear&facet.field=_dokumententyp&facet.field=__mikronav&facet.field=_zielgruppen&facet.field=__doctype&spellcheck.count=2&qt=dismax&fq=__intern:0+OR+__intern:344&hl.fragsize=640&facet.mincount=1&spellcheck.extendedResults=true&json.nl=map&hl.fl=body,+_kurzbeschreibung,+_stichwort&wt=json&spellcheck.collate=true&hl.maxAnalyzedChars=99999&rows=20&spellcheck.onlyMorePopular=false&start=0&facet.sort=index&q=foobar} hits=93 status=0 QTime=113

- we have indexed 115.000 documents, our index size is about 720 MB

any hints where to look? what will the ramBufferSizeMB in mainIndex in solrconfig.xml do? does it make sense to increase this value? should we increase one of your caches? 

- we're using jetty, java jdk 1.6.0_21, java settings are -D64 -server -Xms892m -Xmx2048m -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:-HeapDumpOnOutOfMemoryError -XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled 
- our machine as 4GB of mem and 4 CPUs, load is about 0.6%, the java process seems to use only one CPU, no other services are running on this machine.

- from the beginning we have a master/slave setup. but at the moment we are only working with the master. yesterday i included the slave in our search application, so that half the queries were handled by the master and the other half by the slave. the query times didn't change. so it is not a bottleneck with our machine or I/O or memory. 

- cache stats from admin panel

queryResultCache, LRU Cache(maxSize=65536, initialSize=65536)  
lookups : 1159
hits : 498
hitratio : 0.42  (<=== seems a bit low compared to the other)
inserts : 697
evictions : 0
size : 661
warmupTime : 0
cumulative_lookups : 91470
cumulative_hits : 41370
cumulative_hitratio : 0.45
cumulative_inserts : 52835
cumulative_evictions : 0 

documentCache, LRU Cache(maxSize=32768, initialSize=32768)   
lookups : 53099 
hits : 45429 
hitratio : 0.85 
inserts : 7670 
evictions : 0 
size : 7670 
warmupTime : 0 
cumulative_lookups : 4254335 
cumulative_hits : 3760521 
cumulative_hitratio : 0.88 
cumulative_inserts : 493814 
cumulative_evictions : 0 	

fieldValueCache, Concurrent LRU Cache(maxSize=10000, initialSize=10, minSize=9000, acceptableSize=9500, cleanupThread=false) 
lookups : 3312 
hits : 3306 
hitratio : 0.99 
inserts : 3 
evictions : 0 
size : 3 
warmupTime : 0 
cumulative_lookups : 261969 
cumulative_hits : 261351 
cumulative_hitratio : 0.99 
cumulative_inserts : 306 
cumulative_evictions : 0 
item__zielgruppen : {field=_zielgruppen,memSize=491861,tindexSize=46,time=10,phase1=10,nTerms=46,bigTerms=13,termInstances=53913,uses=1187} 
item___mikronav : {field=__mikronav,memSize=464524,tindexSize=82,time=5,phase1=5,nTerms=39,bigTerms=4,termInstances=18817,uses=1187} 
item___dst : {field=__dst,memSize=464640,tindexSize=66,time=10,phase1=9,nTerms=160,bigTerms=5,termInstances=86516,uses=1187} 
(these are a few of our facet fields)

filterCache Concurrent LRU Cache(maxSize=16384, initialSize=16384, minSize=14745, acceptableSize=15564, cleanupThread=false) 
lookups : 26851 
hits : 26434 
hitratio : 0.98 
inserts : 417 
evictions : 0 
size : 417 
warmupTime : 0 
cumulative_lookups : 1985851 
cumulative_hits : 1959304 
cumulative_hitratio : 0.98 
cumulative_inserts : 26547 
cumulative_evictions : 0 	



Markus Rietzler
<rietzler_software/>
Rechenzentrum der Finanzverwaltung