My points was in support of auto-tune for Ignite's internals. As far as environment, sure, we need to have a doc. -- Nikita Ivanov
On Fri, Sep 1, 2017 at 1:23 PM, Denis Magda <dma...@apache.org> wrote: > 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 > >> > >
