: > previous Solr 1.4 index? what does a directory listing (including file
: > sizes) look like for both your old and new indexes?
:
: Yes, both indexes have same data. Indexes are build using some C++
: programm which reads data from database and inserts it into Solr
: (using XML). Both indexes have about 8GB size and 18milions documents.
I'd still like to see the directory listings with filesizes from both
indexes. I want to make sure there isn't some wonkiness somewhere in
terms of hte number of segments, or huge norms / positions files that you
dont' care about because of how some default might have changed w/o us
realizing it, etc...
: > 2) Did you try using your Solr 1.4 index (and configs) directly in Solr
: > 3.5 w/o rebuilding from scratch?
:
: Yes I used the same configs in solr 1.4 and solr 3.5 (adding only line
: about "luceneMatchVersion")
that wasn't my question -- i'm understand that when you built your
new index you used the same configs as before, i'm asking if you tried
pointing Solr 3.5 at the actual physical index you built with Solr 1.4.
what did you set luceneMatchVersion to?
: Mayby I didn't wrote precisely enough. I have some machine on which
: there is master node. I have second machine on which there is slave. I
: tested solr 1.4 on that machine, then turned it off and turned on
: solr-3.5. I have 36GB RAM on that machine.
: On both - solr 1.4 and 3.5 configuration of JVM is the same, and the
: same servlet container ... jetty-6
So your query performance testing was done running both Solr 1.4 and Solr
3.5 on the same box, but at different times.
what type of machine is this? what OS is it running? (There's been some
work done on making the default Directory implementations auto-detect when
they can use MMap based on OS ... maybe that is guessing poorly in your
case? ... what does admin/mbeans?key=searcher&stats=true say about your
reader and readerDir ?)
: Maybe I wasn't precise enough again. CPU on solr 1.4 was 200% and on
: solr 3.5 1200%
: yes there is cache warming. There are 50-100 client threads on both
: 1.4 and 3.5. There are about 60 requests per second on 3.5 and on 1.4,
: but on 3.5 responses are slower and CPU usage much higher.
Ah... ok ... so when you say 60 req/sec you don't mean that under
continuous load you are measuring that solr 3.5 is maxing out at 60
req/sec ... it now sounds like what you are saying is that
that you have a load testing system which is configured to use at least 50
and at most 100 clients but you also have it configured to try and
generate a stead state load of 60 req/sec, and when you do that you are
seeing higher CPU and slower QTime on Solr 3.5.
...am i understanding that part correctly?
: Most time is in org.apache.solr.handler.component.QueryComponent and
: org.apache.solr.handler.component.DebugComponent in process. I didn't
: comare individual request performance.
Define "most" ? ... if you know that "most" of the time is spent in
QueryComponent that suggests that you did at least one or two individual
requests directly, how fast were they? was the slow performance you are
seeing only under heavy load or was it also slow when you did manual
testing?
-Hoss
