Commercial cloud offerings, such as Amazon's EC2, let users allocate compute resources on demand, charging based on reserved time intervals. While this gives great flexibility to elastic applications, users lack guidance for choosing between multiple offerings, in order to complete their computations within given budget constraints. In this work, we present BaTS, our budget-constrained scheduler. BaTS can schedule large bags of tasks onto multiple clouds with different CPU performance and cost, minimizing completion time while respecting an upper bound for the budget to be spent. BaTS requires no a-priori information about task completion times, and learns to estimate them at run time. We evaluate BaTS by emulating different cloud environments on the DAS-3 multi-cluster system. Our results show that BaTS is able to schedule within a user-defined budget (if such a schedule is possible at all.) At the expense of extra compute time, signifcant cost savings can be achieved when comparing to a cost-oblivious round-robin scheduler.

Commercial cloud offerings, such as Amazon's EC2, let users allocate compute resources on demand, charging based on reserved time intervals. While this gives great flexibility to elastic applications, users lack guidance for choosing between multiple offerings, in order to complete their computations within given budget constraints. In this work, we present BaTS, our budget-constrained scheduler. Using a small task sample, BaTS can estimate costs and makespan for a given bag on different cloud offerings. It provides the user with a choice of options before execution and then schedules the bag according to the user's preferences. BaTS requires no a-priori information about task completion times. We evaluate BaTS by emulating different cloud environments on the DAS-3 multicluster system. Our results show that BaTS correctly estimates budget and makespan for the scenarios investigated; the user-selected schedule is then executed within the given budget limitations.

Abstract-Elastic applications like bags of tasks benefit greatly from Infrastructure as a Service (IaaS) clouds that let users allocate compute resources on demand, charging based on reserved time intervals. Users, however, still need guidance for mapping their applications onto multiple IaaS offerings, both minimizing execution time and respecting budget limitations. For budgetcontrolled execution of bags of tasks, we built BaTS, a scheduler that estimates possible budget and makespan combinations using a tiny task sample, and then executes a bag within the user's budget constraints. Previous work has shown the efficacy of this approach. There remains, however, the risk of outlier tasks causing the execution to exceed the predicted makespan.In this work, we present a stochastic optimization of the tail phase for BaTS' execution. The main idea is to use the otherwise idling machines up until the end of their (already paidfor) allocation time. Using the task completion time information acquired during the execution, BaTS decides which tasks to replicate onto idle machines in the tail phase, reducing the makespan and improving the tolerance to outlier tasks. Our evaluation results show that this effect is robust w.r.t. the quality of runtime predictions and is the strongest with more expensive schedules in which many fast machines are available.

Test smells are poor design decisions implemented in test code, which can have an impact on the effectiveness and maintainability of unit tests. Even though test smell detection tools exist, how to rank the severity of the detected smells is an open research topic. In this work, we aim at investigating the severity rating for four test smells and investigate their perceived impact on test suite maintainability by the developers. To accomplish this, we first analyzed some 1,500 open-source projects to elicit severity thresholds for commonly found test smells. Then, we conducted a study with developers to evaluate our thresholds. We found that (1) current detection rules for certain test smells are considered as too strict by the developers and (2) our newly defined severity thresholds are in line with the participants' perception of how test smells have an impact on the maintainability of a test suite.

The Multi-class Queueing Network (McQN) arises as a natural multi-class extension of the traditional (single-class) Jackson network. In a single-class network subcriticality (i.e. subunitary nominal workload at every station) entails stability, but this is no longer sufficient when jobs/customers of different classes (i.e. with different service requirements and/or routing scheme) visit the same server; therefore, analytical conditions for stability of McQNs are lacking, in general. In this note we design a numerical (simulation-based) method for determining the stability region of a McQN, in terms of arrival rate(s). Our method exploits certain (stochastic) monotonicity properties enjoyed by the associated Markovian queue-configuration process. Stochastic monotonicity is a quite common feature of queueing models and can be easily established in the single-class framework (Jackson networks); recently, also for a wide class of McQNs, including first-come-first-serve (FCFS) networks, monotonicity properties have been established. Here, we provide a minimal set of conditions under which the method performs correctly. Eventually, we illustrate the use of our numerical method by presenting a set of numerical experiments, covering both single and multi-class networks.