We have to fix our downloads and configurations

["Michael J. Carey" <mj...@ics.uci.edu>]

Naive users are routinely ending up with multiple node demo clusters and
not realizing what they are doing or getting.  Then they performance test
and judge the system accordingly.  Not beneficial!

Re: We have to fix our downloads and configurations

[Mike Carey <dt...@gmail.com>]

If you look at https://asterixdb.apache.org/docs/0.9.4/ncservice.html, 
which is prominently linked-to from the docs, what new users get is 
information about "Starting a small single-machine cluster using the 
NCService".  This is of course a bad idea for any real usage - it is 
only useful as a sample, so that AsterixDB explorers can play around 
with a "cluster" on their laptops. Unfortunately, moderately intelligent 
users have actually been known to declare this as the ""sterixDB default 
configuration and then benchmark the system against it, using other 
systems and their default configurations.  We should have one CC and one 
NC - and with spinning disks, one partition per device, and with SSD, 
several partitions per device (determined by cores).  I think it's A Bad 
Thing that what one currently gets, if one's not thinking, is something 
we wouldn't want anyone to ever really use.....

On 12/16/18 3:54 PM, Ian Maxon wrote:
> What should we fix? The one thing I can think of that is a bit
> out-dated is the page size, and perhaps the # of nodes could be
> configured automatically depending on the number of hardware threads
> and disk type. However that still wouldn't prevent people from blindly
> testing without thinking carefully about the configuration. Perhaps
> some sort of limitation that is added in the demo config to stop
> benchmarking but still allow simple use/evaluation , so it forces one
> to look at the documentation to discover how to remove it (and hence
> at least view the other config parameters)?
>
> On Sun, Dec 16, 2018 at 8:58 PM Michael J. Carey <mj...@ics.uci.edu> wrote:
>> Naive users are routinely ending up with multiple node demo clusters and
>> not realizing what they are doing or getting.  Then they performance test
>> and judge the system accordingly.  Not beneficial!

Re: We have to fix our downloads and configurations

[Ted Dunning <te...@gmail.com>]

At MapR (mostly unrelated to asterix), we deployed a system readiness test
that is intended to be run before installing our system.

The point is to set expectations. If a simple test says that your hardware
or network is deficient or severely misconfigured even before the real
software is installed, users are less likely to expect miracles.

See https://github.com/jbenninghoff/cluster-validation



On Sun, Dec 16, 2018 at 3:54 PM Ian Maxon <im...@uci.edu> wrote:

> What should we fix? The one thing I can think of that is a bit
> out-dated is the page size, and perhaps the # of nodes could be
> configured automatically depending on the number of hardware threads
> and disk type. However that still wouldn't prevent people from blindly
> testing without thinking carefully about the configuration. Perhaps
> some sort of limitation that is added in the demo config to stop
> benchmarking but still allow simple use/evaluation , so it forces one
> to look at the documentation to discover how to remove it (and hence
> at least view the other config parameters)?
>
> On Sun, Dec 16, 2018 at 8:58 PM Michael J. Carey <mj...@ics.uci.edu>
> wrote:
> >
> > Naive users are routinely ending up with multiple node demo clusters and
> > not realizing what they are doing or getting.  Then they performance test
> > and judge the system accordingly.  Not beneficial!
>

Re: We have to fix our downloads and configurations

[Ian Maxon <im...@uci.edu>]

What should we fix? The one thing I can think of that is a bit
out-dated is the page size, and perhaps the # of nodes could be
configured automatically depending on the number of hardware threads
and disk type. However that still wouldn't prevent people from blindly
testing without thinking carefully about the configuration. Perhaps
some sort of limitation that is added in the demo config to stop
benchmarking but still allow simple use/evaluation , so it forces one
to look at the documentation to discover how to remove it (and hence
at least view the other config parameters)?

On Sun, Dec 16, 2018 at 8:58 PM Michael J. Carey <mj...@ics.uci.edu> wrote:
>
> Naive users are routinely ending up with multiple node demo clusters and
> not realizing what they are doing or getting.  Then they performance test
> and judge the system accordingly.  Not beneficial!

Re: We have to fix our downloads and configurations

[Ted Dunning <te...@gmail.com>]

I didn't see the tweet that way.

The current difficulty (users installing non-production trial config and
using it inappropriately) is better than the converse (users not installing
production config because it is onerous to do and never using the software
at all).

Whether you make trial easier (and run the risk of inappropriate use) or
make defaults much more realistic for production use (and run the risk of
killing adoption) is a really hard question. In my $dayjob, we opt for the
second, but pay a stiff price. I think open source projects do much better
opting for adoption as Asterix has done.


On Mon, Dec 17, 2018 at 1:02 PM Mike Carey <dt...@gmail.com> wrote:

> (Wow, rereading this, it sounds a bit too much like the tone of a Trump
> tweet...  Ugh. :-))
>
> On 12/16/18 12:57 PM, Michael J. Carey wrote:
> > Naive users are routinely ending up with multiple node demo clusters and
> > not realizing what they are doing or getting.  Then they performance test
> > and judge the system accordingly.  Not beneficial!
> >
>

Re: We have to fix our downloads and configurations

[Mike Carey <dt...@gmail.com>]

(Wow, rereading this, it sounds a bit too much like the tone of a Trump 
tweet...  Ugh. :-))

On 12/16/18 12:57 PM, Michael J. Carey wrote:
> Naive users are routinely ending up with multiple node demo clusters and
> not realizing what they are doing or getting.  Then they performance test
> and judge the system accordingly.  Not beneficial!
>