mesos-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mesos Reviewbot Windows <revi...@mesos.apache.org>
Subject Re: Review Request 67228: Added allocator benchmark test for various simulations.
Date Sat, 19 May 2018 03:31:16 GMT

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



PASS: Mesos patch 67228 was successfully built and tested.

Reviews applied: `['66981', '66982', '66983', '66984', '66990', '66994', '67226', '67227',
'67228']`

All the build artifacts available at: http://dcos-win.westus.cloudapp.azure.com/mesos-build/review/67228

- Mesos Reviewbot Windows


On May 19, 2018, 12:05 a.m., Till Toenshoff wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/67228/
> -----------------------------------------------------------
> 
> (Updated May 19, 2018, 12:05 a.m.)
> 
> 
> Review request for mesos, Benjamin Mahler, Greg Mann, Kapil Arya, and Vinod Kone.
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> This benchmark measures the performannce of the DRF allocator.
> 
> * Accept rate (`min_accept_rate`, `max_accept_rate`, and
>   `accept_rate_divisor`): Each framework is initialized with a given
>   offer accept-rate. This rate determines the number of offers
>   accepted out of the total received.
>   The first framework is launched with `max_accept_rate`. Each
>   subsequent framework is launched with an accept rate of
>   (previous framework's accept-rate / `accept_rate_divisor`). This
>   rate will never be below `min_accept_rate`.
>   For example, with a `max_accept_rate` of 1 and `accept_rate_divisor`
>   of 2, the framework accept rates will be 1, 0.5, 0.25, 0.125, and
>   so on.
> 
> 
> * Terminating condition(s): the benchmark stops if any of the
>   following condition is met:
>     * Number of offers generated reaches `max_offers`.
>     * Number of total tasks launched reaches `max_tasks`.
>     * Any single framework launches `max_framework_tasks` tasks.
> 
> 
> * Offer decline timeout (`decline_timeout` and
>   `partial_decline_timeout`): When declining an entire offer, the
>   offer-filter timeout is set to `decline_timeout` for a given slave.
>   If an offer is partially accepted, the offer-filter timeout is set
>   to `partial_decline_timeout`. If the two timeouts are the same,
>   framework starvation is observed for framework with the highest
>   accept rate. To avoid such starvation, one can try setting
>   `decline_timeout` to be significantly higher (e.g., 10x) than
>   `partial_decline_timeout`.
> 
> 
> Diffs
> -----
> 
>   src/Makefile.am c08ac6e2f5deec4d05f59f71ff6c51382f216708 
>   src/tests/master_drf_benchmarks.cpp PRE-CREATION 
> 
> 
> Diff: https://reviews.apache.org/r/67228/diff/1/
> 
> 
> Testing
> -------
> 
> WIP - still validating results - WIP
> 
> 
> Thanks,
> 
> Till Toenshoff
> 
>


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