Hi List, Fred,
After a week of going cross-eyed looking at stats & trying to engineer a
test case to make this happen in the test env I think I've made a
breakthrough.
We have a low but steady level of riak traffic but our application level
actions that result in solr reads are actually fairly in
Hi Fred,
Thanks for taking the time!
Yes, I noticed that unbalance yesterday when writing, looked into it after
sending and found our config is corrupt with one node ommitted and another
in there twice.
But, with such low traffic levels and the spikes being on the non-favoured
node I'm not current
It's pretty strange that you are seeing no search latency measurements on node
5. Are you sure your round robining is working? Are you favoring node 1?
In general, I don't think which node you hit for query should make a
difference, but I'd have to stare at the code some to be sure. In essenc
Hi Fred,
Thanks for the pointer! 'cursorMark' is a lot more performant alright,
though apparently it doesn't suit our use case.
I've written a loop function using OTP's httpc that reads each page, gets
the cursorMark and repeats, and it returns all 147 pages with consistent
times in the 40-60ms b
All great questions, Sean.
A few things. First off, for result sets that are that large, you are probably
going to want to use Solr cursor marks [1], which are supported in the current
version of Solr we ship. Riak allows queries using cursor marks through the
HTTP interface. At present, it
Hi Jason,
Gary Flake and the crew at Clipboard submitted a pull request on this
ticket a while back:
http://lists.basho.com/pipermail/riak-users_lists.basho.com/2011-May/004219.html
We merged in the changes (with a little tweaking) in this pull
request: https://github.com/basho/riak_search/pull/5
