Go easy on your use of commit - use the <autocommit /> section solrconfig.xml instead.
Also consider using optimize() once a day if you are doing lots of adds/removes.
(PECL solr >= 0.9.2)
SolrClient::commit — Finalizes all add/deletes made to the index
$maxSegments= 0 [, bool
$softCommit= false [, bool
$waitSearcher= true [, bool
$expungeDeletes= false ]]]] )
This method finalizes all add/deletes made to the index.
Does nothing, kept for backward compatibility
DEPRECATED: will be removed in the next release.
This will refresh the 'view' of the index in a more performant manner, but without "on-disk" guarantees. (Solr4.0+)
A soft commit is much faster since it only makes index changes visible and does not fsync index files or write a new index descriptor. If the JVM crashes or there is a loss of power, changes that occurred after the last hard commit will be lost. Search collections that have near-real-time requirements (that want index changes to be quickly visible to searches) will want to soft commit often but hard commit less frequently.
block until a new searcher is opened and registered as the main query searcher, making the changes visible.
Merge segments with deletes away. (Solr1.4+)
Returns a SolrUpdateResponse object on success or throws a SolrClientException on failure.
|2.0.0||API Changed: SolrClient::commit ([ int $maxSegments = 0 [, bool $softCommit = false [, bool $waitSearcher = true[, bool $expungeDeletes = false ]]] )|
|0.9.2||Signature: SolrClient::commit ([ int $maxSegments = 1 [, bool $waitFlush = true [, bool $waitSearcher = true ]]] ). $waitFlush: Block until index changes are flushed to disk.|
PECL Solr >= 2.0 only supports Solr Server >= 4.0