Hello Roshan, Thank you for your detailed answer. Details are important, because in my organization, I am often asked to re-assess the reasons why we chose Storm over its competitors.
Best regards, Alexandre Vermeerbergen 2017-07-25 23:36 GMT+02:00 roshannaik <g...@git.apache.org>: > Github user roshannaik commented on the issue: > > https://github.com/apache/storm/pull/2241 > > @avermeer Looks like SuperChief blog is relaying the same basic claims > that Heron has marketed. Since you ask, i will share my opinions wrt > Heron's claims. > > - Heron has never been a player in the high performance club. They > have been smart about not comparing themselves with the real top performers > of the day. I only included them here because they have built they have > made much noise against Storm. They are smart about not mentioning which > version of Storm they are comparing with (how does a paper with such > critical info missing get accepted ?). That creates an illusion in people > that their perf claims apply to all versions of Storm in general... even if > Storm [publishes new perf numbers](hortonworks.com/blog/ > microbenchmarking-storm-1-0-performance/) comparing itself to a prior > version. > - Heron's threading model (1 thread per process.. based on what i > gather from their articles), is really primitive for this application > domain. I don't recommend it, but by setting 'topology.workers' equal to > the number of spout& bolt instances, Storm can be run in Heron mode. > - I find it much easier to debug a process with multiple components > using a debugger rather start a separate debugger for every instance of > spout bolt running. Also, I would imagine, having so many processes means > you have an explosion of log files to deal with when triaging. > - Unclear why the recovery model (when worker process crashes) is any > better ... the same kind of replay from the spout would be required. The > gains may be minor if any. Making minor optimizations to the failure path > and penalizing the normal operation path... is backwards. > - Cant get a stack from a Storm worker ? Thats clearly false. Try it > yourself. I do it all the time. Heapdumps, on the other hand, can stall the > worker and if the heap size is really large the supervisor might feel the > worker is having a problem. There are timeouts that you can increase to for > the supervisor to wait longer. I cant imagine that Heron doesn't monitor > their workers and restart them if they are not responsive. > - Heron's Backpressure model is simply too overweight, but marketed > as a novel idea. > - A quick read of their latest perf blog, noted in the comparison, and > it was evident that they missed recognizing their real perf problem. > > > > --- > If your project is set up for it, you can reply to this email and have your > reply appear on GitHub as well. If your project does not have this feature > enabled and wishes so, or if the feature is enabled but not working, please > contact infrastructure at infrastruct...@apache.org or file a JIRA ticket > with INFRA. > --- >
