You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@lucene.apache.org by Apache Wiki <wi...@apache.org> on 2018/09/18 14:09:53 UTC

[Solr Wiki] Update of "SolrPerformanceProblems" by ShawnHeisey

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Solr Wiki" for change notification.

The "SolrPerformanceProblems" page has been changed by ShawnHeisey:
https://wiki.apache.org/solr/SolrPerformanceProblems?action=diff&rev1=88&rev2=89

Comment:
Added section about request rate.

  !ZooKeeper's design assumes that it has extremely fast access to its database.  If the !ZooKeeper database is stored on the same disks that hold the Solr data, any performance problems with Solr will delay !ZooKeeper's access to its own database.  This can lead to a performance death spiral where each ZK timeout results in recovery operations which cause further timeouts.
  
  !ZooKeeper holds its database in Java heap memory, so disk read performance isn't quite as critical as disk write performance.  In situations where the OS disk cache is too small for Solr's needs and the ZK database is on the same disk as Solr data, a large amount of disk access for Solr can interfere with ZK writes.  Using very fast disks for ZK (SSD in particular) will result in good performance.  Using separate physical disks for Solr and ZK data is strongly recommended.  Having dedicated machines for all ZK nodes (a minimum of three nodes are required for redundancy) is even better, but not strictly a requirement.
+ 
+ == High Request Rate ==
+ 
+ If your request rate is high, that will impact performance, often very dramatically.  Determining what qualifies as "high" is not straightforward.  Some servers can easily handle 200 requests per second, others will struggle to handle 10 per second.  If your request rate is above about 30 per second, it's probably time to think about scaling your install by adding additional copies of your index and additional servers.  Handling thousands of requests per second will require a LOT of hardware.
+ 
+ Handling a high query rate usually involves setting up multiple copies of your index on multiple servers and implementing some kind of load balancing.  SolrCloud can automate a lot of this, and it does load balancing internally, but you might still need an external load balancer.
  
  == RAM ==