I'm using a Solr 1.4 nightly from around July. Is that recent enough to have the improved reader implementation? I'm not sure whether you'd call my operations IO heavy -- each query has so many terms (~50) that even against a 45K document index a query takes 130ms, but the entire index is in a ramfs. - Michael
On Tue, Sep 22, 2009 at 8:08 PM, Yonik Seeley <yo...@lucidimagination.com>wrote: > What version of Solr are you using? > Solr1.3 and Lucene 2.4 defaulted to an index reader implementation > that had to synchronize, so search operations that are IO "heavy" > can't proceed in parallel. You shouldn't see this with 1.4 > > -Yonik > http://www.lucidimagination.com > > > > On Tue, Sep 22, 2009 at 4:03 PM, Michael <solrco...@gmail.com> wrote: > > Hi, > > I have a Solr+Tomcat installation on an 8 CPU Linux box, and I just tried > > sending parallel requests to it and measuring response time. I would > expect > > that it could handle up to 8 parallel requests without significant > slowdown > > of any individual request. > > > > Instead, I found that Tomcat is serializing the requests. > > > > For example, the response time for each of 2 parallel requests is nearly > 2 > > times that for a single request, and the time for each of 8 parallel > > requests is about 4 times that of a single request. > > > > I am pretty sure this is a Tomcat issue, for when I started 8 identical > > instances of Solr+Tomcat on the machine (on 8 different ports), I could > send > > one request to each in parallel with only a 20% slowdown (compared to > 300% > > in a single Tomcat.) > > > > I'm using the stock Tomcat download with minimal configuration changes, > > except that I disabled all logging (in case the logger was blocking for > each > > request, serializing them.) I'm giving 2G RAM to each JVM. > > > > Does anyone more familiar with Tomcat know what's wrong? I can't imagine > > that Tomcat really can't handle parallel requests. > > >
