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 <c...@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 >
