So I have been testing search times of KinoSearch -r3875 vs Solr..
I'm not trying to do a full test matrix just testing it on a few
things I would like to use KinoSearch for.
I'm pretty limited in my Solr knowledge and for that matter KinoSearch
but from the few tests I have done.
KinoSearch Seems to do pretty well when the number of hits (doc hits) are low...
But as the hits go up it starts falling back quickly. Searching on one
term with one value. (foo:commonvalue),
Once I start asking for more that one value both with large hits it
gets real bad. i.e. (foo:common OR foo:morecommon)
So now I have made claims... :)
I'll try to give more details.
My test.
I built a small index (about 1M docs) in both indexes trying to set
the index up with the same settings in both.
I removed the solr Doc Caching,Query Caching (my simple Search app
did no caching)
They are both running on the same box with the indexes on the same raid drive
The indexes are optimized and read only (no writes touching them)
The box has 8G Ram and doing nothing else (both indexes are for sure
in disk cache)
Java was Given 1G Ram (after all the testing using about Res:57M Virt:1194m)
My FastCGI worker after all the test was using < 9M of Ram
I wrote a simple test perl script to query the index's this script
using keep alives to the searchers (one at a time) and runs the same
search n-times returning only 1 Hit result per search and times the
whole process..
Ran this script on another box doing nothing but my test.
So as you can see this whole "test" is pretty simple with many
possible holes to try and get this Apples Vs Oranges test running.
But regardless.. After adding some profiling in my FastCGI app it
seems pretty clear 99% of the time for these large result searches are
in the $searcher->search(query => $query, num_wanted => 1) as one
would expect. Is there anything I can do to make these searches
perform better? What data could I provide to help?
Thanks,
-Dan
_______________________________________________
KinoSearch mailing list
KinoSearch@rectangular.com
http://www.rectangular.com/mailman/listinfo/kinosearch
I'm not trying to do a full test matrix just testing it on a few
things I would like to use KinoSearch for.
I'm pretty limited in my Solr knowledge and for that matter KinoSearch
but from the few tests I have done.
KinoSearch Seems to do pretty well when the number of hits (doc hits) are low...
But as the hits go up it starts falling back quickly. Searching on one
term with one value. (foo:commonvalue),
Once I start asking for more that one value both with large hits it
gets real bad. i.e. (foo:common OR foo:morecommon)
So now I have made claims... :)
I'll try to give more details.
My test.
I built a small index (about 1M docs) in both indexes trying to set
the index up with the same settings in both.
I removed the solr Doc Caching,Query Caching (my simple Search app
did no caching)
They are both running on the same box with the indexes on the same raid drive
The indexes are optimized and read only (no writes touching them)
The box has 8G Ram and doing nothing else (both indexes are for sure
in disk cache)
Java was Given 1G Ram (after all the testing using about Res:57M Virt:1194m)
My FastCGI worker after all the test was using < 9M of Ram
I wrote a simple test perl script to query the index's this script
using keep alives to the searchers (one at a time) and runs the same
search n-times returning only 1 Hit result per search and times the
whole process..
Ran this script on another box doing nothing but my test.
So as you can see this whole "test" is pretty simple with many
possible holes to try and get this Apples Vs Oranges test running.
But regardless.. After adding some profiling in my FastCGI app it
seems pretty clear 99% of the time for these large result searches are
in the $searcher->search(query => $query, num_wanted => 1) as one
would expect. Is there anything I can do to make these searches
perform better? What data could I provide to help?
Thanks,
-Dan
_______________________________________________
KinoSearch mailing list
KinoSearch@rectangular.com
http://www.rectangular.com/mailman/listinfo/kinosearch