ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nikita Ivanov <nivano...@gmail.com>
Subject Re: Durable Memory and Ignite Persistence Tuning
Date Fri, 01 Sep 2017 19:49:08 GMT
200% agree.

UX is major problem for Ignite (especially so for 2.0 with all major
redev). Removing (!) configuration properties should be THE GOAL, not
adding new one or documenting them (which is a crutch to begin with).

When I see a product with dozens config properties or more I desperately
look for ways not to use it...

My 2 cents,
--
Nikita Ivanov


On Fri, Sep 1, 2017 at 12:02 PM, Konstantin Boudnik <cos@apache.org> wrote:

> Just to spice it up: in my experience, having a few hundred parameters one
> can
> tweak (I am making up the number here) is a tough UX call. In JVM, we had a
> team that worked on heuristics that would auto-tune a bunch of things
> during
> the VM startup. Hence, providing the best user experience in most cases.
>
> Do you think something like this is feasible in case of persistence
> functionality? Documenting it first is a great first step, but perhaps
> wrapping this knowledge into some soft of code, would be even better.
>
> I do have an anecdotal evidence where an experienced Ignite developer
> tried to implement a message processing system with Ignite 2.0. After a
> week
> of getting nowhere performance wise, he dropped it and implemented
> something
> custom with Java and nothing else. Take it or leave it: that's why I called
> this "anecdotal" in the first place.
>
> Speaking strictly for myself: when I come across blog posts about tuning of
> Apache Kudu or Apache Impala the skin on the back of head starts crawling.
> I
> imagine 95% of the potential users of these applications would turn away
> right
> at that point. If the system doesn't work well enough out of the box -
> screw
> it, there's 355 other alternatives available in the FOSS market.
>
> Thoughts?
>   Cos
>
> On Fri, Sep 01, 2017 at 11:08AM, Denis Magda wrote:
> > Igniters,
> >
> > I see a lot of complains regarding the performance of the subj on the
> user
> > list. At the same time, I do believe that in most scenarios it’s a lack
> of
> > knowledge that we keep in secret.
> >
> > It's time to document Durable Memory and its Native Persistence tuning
> > parameters. Let's start doing this for Linux based deployments first.
> Here
> > is what we have for now (which is almost nothing):
> > https://apacheignite.readme.io/docs/durable-memory-tuning
> > <https://apacheignite.readme.io/docs/durable-memory-tuning>
> >
> > Ideally, at some point we have to come up with doc like this:
> > https://access.redhat.com/sites/default/files/
> attachments/deploying-oracle-12c-on-rhel6_1.2_1.pdf
> >
> > Please share your expertise in a form of settings that have to be put on
> the
> > paper. We put them in JIRA and document afterwords:
> > https://issues.apache.org/jira/browse/IGNITE-6246
> > <https://issues.apache.org/jira/browse/IGNITE-6246>
> >
> > —
> > Denis
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message