The problem with starting without vnodes is moving to them is a bit hairy. In particular, nodetool shuffle has been reported to take an extremely long time (days, weeks). I would start with vnodes if you have any intent on using them.
On Thu, Jul 17, 2014 at 6:03 PM, Robert Coli <rc...@eventbrite.com> wrote: > On Thu, Jul 17, 2014 at 5:16 PM, Diane Griffith <dfgriff...@gmail.com> > wrote: >> >> I did tests comparing 1, 2, 10, 20, 50, 100 clients spawned all querying. >> Performance on 2 nodes starts to degrade from 10 clients on. I saw similar >> behavior on 4 nodes but haven't done the official runs on that yet. > > > Ok, if you've multi-threaded your client, then you aren't starving for > client thread paralellism, and that rules out another scalability > bottleneck. > > As a brief aside, you "only lose" from vnodes until your cluster is larger > than a certain sizes, and then only when adding or removing nodes from a > cluster. Perhaps if you are ramping up and scientifically testing smaller > cluster sizes, you should start at first with a token per range, ie > "pre-vnodes" operation? > >> I basically did the command and it was outputting 256 tokens on each node >> and comma separated. So I tried taking that string and setting that as the >> value to initial_token but the node wouldn't start up. >> >> Not sure if I maybe had a carriage return in there and that was the >> problem. > > > It should take a comma delimited list of tokens, did the failed node startup > log any error? > >> >> And if I do that do I need to do more than comment out num_tokens? > > > No, though you probably should anyway in order to be unambiguous. > > =Rob > -- Jon Haddad http://www.rustyrazorblade.com skype: rustyrazorblade
