FARACost: an adaptation cost model aware of pending constraints

Abstract

The perturbations induced by adaptation and resource allocation decisions on the adapted applications may have the undesirable side effect of causing timing constraint failures. In order to benefit from available adaptation capabilities yet avoid critical timing failures, the dynamic resource allocation mechanism should be aware of the perturbation induced by its decisions. Therefore, the impact of adaptation on short-term performance should be considered a first-class decision criterion, along with traditional criteria such as long-term performance and application criticality. Towards this end, we propose the FARACost, an adaptation cost model that captures the impact of application-specific adaptation procedures and uses this information to evaluate adaptation choices. Experimental evaluations with two applications demonstrate that the use of models like FARACost reduces or prevents pending timing constraint failures, while leading to long-term performance improvements. The experiments are conducted in a cluster environment with a fully implemented infrastructure for adaptation and resource allocation based on the FARA framework.

Performance guarantees for Web server end-systems: a control-theoretical approach

“…For example, the Q-RAM architecture [47] introduces QoS-sensitive near-optimal resource allocation algorithms for applications with multiple resource requirements and multiple QoS dimensions. FARA [49], [48] presents a hierarchical adaptation model for complex real-time systems and algorithms for optimizing multidimensional adaptation cost. An end-to-end QoS model is presented in [32] in the context of a middleware approach to QoS management that requires application cooperation.…”

“…For example, Fig. 8 plots server response time versus request rate when the listen queue was configured for maximum length of 48,192, and 768, respectively. In this experiment, all requests were for URLs of size 64KB.…”

IQ‐Services: network‐aware middleware for interactive large‐data applications

“…One consequence is that reactions to changes in available network bandwidth, for example, can occur at packet boundaries rather than at the boundaries defined by application-level message sizes and/or by applications' time slices. The resulting 'faster' and bounded reaction times can reduce jitter and improve system predictability [15,38]. An important characteristic of our middleware is its support of user-defined 'handlers' -IQ-Services -that implement the actual data adaptations suitable for specific applications.…”

I/O Containers: Managing the Data Analytics and Visualization Pipelines of High End Codes

“…These facts impose limitations on how to manage containers as decisions made upstream, for instance, have a direct effect on downstream operation and they directly affect the end-to-end QoS properties of I/O pipelines [27], [25]. An extreme example is the removal of a component from the I/O pipeline rendering its downstream components useless.…”