Mailing-List: contact reviews-help@aurora.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: reviews@aurora.incubator.apache.org
Content-Type: multipart/alternative;
 boundary="===============5055202101840948606=="
MIME-Version: 1.0
Subject: Re: Review Request 31739: Making task preemption asynchronous.
From: "Zameer Manji" <zmanji@apache.org>
To: "Bill Farner" <wfarner@apache.org>, "Zameer Manji" <zmanji@apache.org>
Cc: "Aurora" <reviews@aurora.incubator.apache.org>,
 "Maxim Khutornenko" <maxim@apache.org>
Date: Wed, 04 Mar 2015 20:14:40 -0000
Message-ID: <20150304201440.12263.3118@reviews.apache.org>
Auto-Submitted: auto-generated
Sender: "Zameer Manji" <noreply@reviews.apache.org>
References: <20150304193027.5896.92873@reviews.apache.org>
In-Reply-To: <20150304193027.5896.92873@reviews.apache.org>
Reply-To: "Zameer Manji" <zmanji@apache.org>

--===============5055202101840948606==
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit


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


src/jmh/java/org/apache/aurora/benchmark/SchedulingBenchmarks.java
<https://reviews.apache.org/r/31739/#comment122186>

    I think a comment would help explain why 30 Days is the desired value to use for the benchmarks.


src/main/java/org/apache/aurora/scheduler/async/TaskScheduler.java
<https://reviews.apache.org/r/31739/#comment122189>

    Can you explain the reason for the delay? We already wait for a task to be pending for 10 minutes before we do preemption, I don't see the reason for another delay until we look for a victim.


- Zameer Manji


On March 4, 2015, 11:30 a.m., Maxim Khutornenko wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/31739/
> -----------------------------------------------------------
> 
> (Updated March 4, 2015, 11:30 a.m.)
> 
> 
> Review request for Aurora, Bill Farner and Zameer Manji.
> 
> 
> Bugs: AURORA-1158
>     https://issues.apache.org/jira/browse/AURORA-1158
> 
> 
> Repository: aurora
> 
> 
> Description
> -------
> 
> Reservations now happen asynchronously with a configurable delay between a failed task scheduling and a preemption attempt.
> 
> Added a new `PreemptorBenchmark` to measure preemption perf as it now happens off the main scheduling loop and thus unreachable by earlier benchmarks.
> 
> Benchmark results are unsurprisingly great. The biggest winner is the PreemptorFallbackForLargeClusterBenchmark (now ClusterFullUtilizationBenchmark). Without the preemptor fallback and thanks to static veto offer filtering it's now 99.995% faster :) 
> 
> The lowest gain is for the limit constraint benchmark. It's the only dynamic veto type and thus is not subjected to offer filtering. Still ~71% improvement is nothing to complain about.
> 
> Before:
> Benchmark                                                                     Mode  Cnt         Score        Error  Units
> SchedulingBenchmarks.InsufficientResourcesSchedulingBenchmark.runBenchmark    avgt  100    781243.004 Â±   9308.450  ns/op
> SchedulingBenchmarks.LimitConstraintMismatchSchedulingBenchmark.runBenchmark  avgt  100   1205278.826 Â±  19800.452  ns/op
> SchedulingBenchmarks.PreemptorFallbackForLargeClusterBenchmark.runBenchmark   avgt  100  77048458.974 Â± 918593.702  ns/op
> SchedulingBenchmarks.ValueConstraintMismatchSchedulingBenchmark.runBenchmark  avgt  100    769919.326 Â±  18963.264  ns/op
> 
> 
> After:
> Benchmark                                                                     Mode  Cnt        Score        Error  Units
> SchedulingBenchmarks.InsufficientResourcesSchedulingBenchmark.runBenchmark    avgt  100    28117.603 Â±    243.556  ns/op
> SchedulingBenchmarks.LimitConstraintMismatchSchedulingBenchmark.runBenchmark  avgt  100   348667.808 Â±   2956.521  ns/op
> SchedulingBenchmarks.ClusterFullUtilizationBenchmark.runBenchmark             avgt  100     3978.828 Â±    351.186  ns/op
> SchedulingBenchmarks.ValueConstraintMismatchSchedulingBenchmark.runBenchmark  avgt  100    26096.782 Â±    412.138  ns/op
> SchedulingBenchmarks.PreemptorBenchmark.runBenchmark                          avgt  100  6054216.773 Â± 105428.318  ns/op
> 
> Perf gain summary:
> InsufficientResourcesSchedulingBenchmark     - 96.4%
> LimitConstraintMismatchSchedulingBenchmark   - 71%
> PreemptorFallbackForLargeClusterBenchmark    - 99.995%
> ValueConstraintMismatchSchedulingBenchmark   - 96.6%
> 
> 
> Diffs
> -----
> 
>   src/jmh/java/org/apache/aurora/benchmark/SchedulingBenchmarks.java 3239eaa139e35e8c3acdacf6375f492de2b5bfee 
>   src/main/java/org/apache/aurora/scheduler/async/AsyncModule.java e87dda47a355654c66f6f54fb25a4d9a7f68422d 
>   src/main/java/org/apache/aurora/scheduler/async/TaskScheduler.java d0fe3e133cbec2418f31160bf8ab8adaa45bb958 
>   src/test/java/org/apache/aurora/scheduler/async/TaskSchedulerImplTest.java 4ee13c8e5d46ba863f4d9871884c7d494d07758d 
>   src/test/java/org/apache/aurora/scheduler/async/TaskSchedulerTest.java 87bc531d2a72f21c36ddd0c1bd3b2367826cc422 
> 
> Diff: https://reviews.apache.org/r/31739/diff/
> 
> 
> Testing
> -------
> 
> ./gradlew -Pq build
> Manual testing in vagrant.
> 
> 
> Thanks,
> 
> Maxim Khutornenko
> 
>


--===============5055202101840948606==--