Hi, Loading paragraphs Incrementally might be a possible way to reduce data handling in front-end side. But I haven't seen any issue related to this subject.
I think 'Run All Paragraph' submit all paragraphs at once. All execution of paragraph is depends on scheduler of each Interpreter. for example, If you're paragraphs are using SparkSQL (%sql), set 'zeppelin.spark.concurrentSQL' property 'true' in Interpreter menu will allow run paragraphs concurrently on 'Run All Paragraph' Thanks, moon On Tue, Apr 26, 2016 at 12:46 AM ashish rawat <dceash...@gmail.com> wrote: > The display problem was mainly because of huge data transfer to UI. I have > reduced the data and now it takes around 4-5s, which is acceptable for my > case. > > I believe there should be a provision to incrementally load paragraphs. > Since I had 9 charts/paragraphs, it was taking 10-15s to load them all and > then display. Had the UI started displaying the data after receiving each > paragrah, the experience would have been better. > > Is something being done in this direction? Also, I believe zeppelin > executes one paragraph at a time in the server side, are there any plans to > make it concurrent, else the "Run All Paragraph" options takes ages to run. > > In general, I was wondering that whether zeppelin is being developed only > for ad-hoc analytics or Dashboards and Reporting are also important > targets? Since the issues I have mentioned above, do not affect ad-hoc > analysis a lot, but I believe Zeppelin can be a great Dashboard/Reporting > tool as well. > > > Regards, > Ashish > > On Tue, Apr 26, 2016 at 10:32 AM, ashish rawat <dceash...@gmail.com> > wrote: > >> Yes, I am referring to the total time in fetching and displaying. Does >> zeppelin server send the complete notebook data to browser? I couldn't see >> much data getting transferred in Chrome Developer Tools and nothing in web >> socket, while I thought that Server must be transferring 3-4 MB of data >> through web sockets. >> >> I am not able to attach a profiling tool, because of server side >> restrictions, would try to do offline analysis. >> >> Regards, >> Ashish >> >> On Tue, Apr 26, 2016 at 7:23 AM, moon soo Lee <m...@apache.org> wrote: >> >>> Hi Ashish, >>> >>> While ZeppelinServer and Interpreter process are running on JVM, I think >>> any JVM profiling tool can be attached to the process. >>> >>> When you're experiencing 10-15s time to retrieve a notebook, is the time >>> includes notebook being displayed on your webbrowser or not? >>> >>> Thanks, >>> moon >>> >>> >>> On Mon, Apr 25, 2016 at 11:51 AM ashish rawat <dceash...@gmail.com> >>> wrote: >>> >>>> I have noticed that since I am not re-running the queries, results are >>>> being saved in zeppelin notebook and fetched from there. Each notebook is >>>> approx 3-4MB. Can zeppelin take 10-15s to retrieve a notebook of this size >>>> or am I missing something. I have given sufficiently big memory to >>>> zeppelin, but it seems that it doesn't even cache the notebooks. Is that >>>> correct? >>>> >>>> Regards, >>>> Ashish >>>> >>>> On Mon, Apr 25, 2016 at 11:05 PM, ashish rawat <dceash...@gmail.com> >>>> wrote: >>>> >>>>> Hello folks, >>>>> >>>>> Is there any quick way of debugging the performance issues of >>>>> zeppelin. I am facing serious performance issues in serving zeppelin >>>>> notebooks. A notebook with 6-7 graphs is taking upto 10-15 secs to load, >>>>> with just 3000 tuples in elastic search. I believe the problem is at the >>>>> Zeppelin server or interpreter level, but can't find a good way to >>>>> debugging it. Is there a good way of checking Zeppelin performance or any >>>>> recommendation on making it run faster. >>>>> >>>>> Regards, >>>>> Ashish >>>>> >>>> >>>> >> >
