aurora-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Farner" <wfar...@apache.org>
Subject Re: Review Request 25721: Asynchronous JS for Scheduler UI
Date Wed, 17 Sep 2014 04:28:53 GMT


> On Sept. 17, 2014, 12:52 a.m., Bill Farner wrote:
> > > This is because the getJobSummary requests is 10KB compared to <1KB in the
sync version.
> > 
> > I didn't grok this part.  The _request_ is 10 KB?  Nonetheless, why does sync/async
change data representation in either direction?
> 
> David McLaughlin wrote:
>     I took the screenshot on master before I started working on this and my hello_word
job had 1 active task and 0 complete tasks. I left that flapping task running while I worked
on async, which generated an extra 100 bad completed tasks which obviously increased the size
of the response.

Oh i see, these requests/responses were just plain different.  Thanks!


- Bill


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/25721/#review53630
-----------------------------------------------------------


On Sept. 17, 2014, 12:48 a.m., David McLaughlin wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/25721/
> -----------------------------------------------------------
> 
> (Updated Sept. 17, 2014, 12:48 a.m.)
> 
> 
> Review request for Aurora, Joshua Cohen, Kevin Sweeney, and Bill Farner.
> 
> 
> Bugs: AURORA-700
>     https://issues.apache.org/jira/browse/AURORA-700
> 
> 
> Repository: aurora
> 
> 
> Description
> -------
> 
> Asynchronous JS for Scheduler UI.
> 
> I have tried to change the minimum amount of JavaScript to keep this review small, even
though doing this made me really want to tear everything up and start again :-)
> 
> I attached two screenshots to show the sync vs async behaviour in the browser - note
that the async version is 2x the latency of the first. This is because the getJobSummary requests
is 10KB compared to <1KB in the sync version. The point is how work is done in parallel.

> 
> 
> Diffs
> -----
> 
>   src/main/resources/org/apache/aurora/scheduler/http/ui/job.html 14dce65158eab83906c68f9afabf49e39283287d

>   src/main/resources/org/apache/aurora/scheduler/http/ui/js/controllers.js 0884cc8f0504a953ef694dae0e6b05ba6e2bff61

>   src/main/resources/org/apache/aurora/scheduler/http/ui/js/services.js c80146aa3829e3c3102645a1864dbeaf5e2e56bc

> 
> Diff: https://reviews.apache.org/r/25721/diff/
> 
> 
> Testing
> -------
> 
> ./gradlew jsHint
> 
> I did manual testing to verify I didn't accidentally introduce any regressions. I have
around 80% confidence there are no regressions here, mainly because I wasted an hour on totally
unintuitive behaviour from SmartTable. So I'm going to do a bunch more testing, which will
involve mocks for updates and crons.
> 
> 
> File Attachments
> ----------------
> 
> Before: Synchronous, serial evaluation of network requests.
>   https://reviews.apache.org/media/uploaded/files/2014/09/17/ce60917a-5c25-4600-8c1f-cc816aa96a5e__before-sync.png
> AFTER: Asynchronous, parallel network requests.
>   https://reviews.apache.org/media/uploaded/files/2014/09/17/dc703579-7072-4aa0-b51a-6df99521fcd5__after-async.png
> 
> 
> Thanks,
> 
> David McLaughlin
> 
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message