It doesn’t matter how many configuration parameters your platform, database or operating system has - the performance tuning usually takes place in business deployments. The performance optimizations might happen behind the scene by heuristic algorithms or basic checks or be explained in performance guides or both.
This discussion is about this exact guide that is vital for DevOps and Admins. Make it first and you’ll reveal the spots for auto-tuning. Otherwise, we can spend months keeping a blind eye on this problem waiting for fully automated heaven and cleanest API in the world but nothing will happen at all. — Denis > On Sep 1, 2017, at 12:49 PM, Nikita Ivanov <nivano...@gmail.com> wrote: > > 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 >>
