the old SolrTest app had some code in it for spinning up multiple threads to hammer Solr with a random entry from dictionary of searches/updates...
http://svn.apache.org/viewvc/incubator/solr/trunk/src/apps/SolrTest/?pathrev=480682 ...if Yonik doesn't even remember it, then it might just be better to start from scratch (it was his baby back before i convinced him JUnit was useful) : Date: Tue, 6 Mar 2007 20:44:10 -0500 : From: Yonik Seeley <[EMAIL PROTECTED]> : Reply-To: solr-dev@lucene.apache.org : To: solr-dev@lucene.apache.org : Subject: Re: /update performance testing : : Nothing that I know of, but I've been considering writing a python : script to hammer Solr with multiple threads to check for concurrency : issues. Something to check for performance would be nice as well. : : -Yonik : : On 3/6/07, Ryan McKinley <[EMAIL PROTECTED]> wrote: : > does anyone have performance testing scripts for /update? : > : > The three key things i'd like to test are: : > : > * SOLR-139, i'd like to make sure using the IndexDocumentCommand : > (without modifying the existing document) is equivalent to what we : > have. : > : > * /update as servlet vs /update/xml as filter -- *should* be the same : > : > * most importantly, SOLR-133 - i've been using StAX in a bunch of : > custom handlers - its much easier then XPP and purports to be equally : > fast. we should make sure. : > : > Any pointers would be great. : > : > It would be nice to have a performance test in /trunk that adds a ton : > of files and spits back timing info. : > : > thanks : > ryan : > : -Hoss
