Commit d514347b authored by Simon Eismann's avatar Simon Eismann
Browse files

removed most warnings + bad boxes

parent 5e0fd258
No preview for this file type
......@@ -9,11 +9,7 @@
%Draft Watermark
%\usepackage{draftwatermark}
%\SetWatermarkLightness{0.9}
\graphicspath{
{figures/}
}
\graphicspath{{figures/}}
\usepackage{cleveref}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
......@@ -46,7 +42,7 @@
\renewcommand*{\acronymname}{List of Acronyms and Abbreviations}
\renewcommand{\glsnamefont}[1]{\textbf{#1}}
\newglossarystyle{acrnogroupskip}{%
\glossarystyle{super}%
\setglossarystyle{super}%
\renewcommand{\glsgroupskip}{}
}
\input{acronyms}
......
%!TEX root=../../DML.tex
This technical report introduces the \acrfull{dml}, a new architecture-level modeling language for modeling Quality-of-Service (QoS) and resource management related aspects of modern dynamic IT systems, infrastructures and services. \gls{dml} is designed to serve as a basis for \emph{self-aware} resource management\footnote{The interpretation of the term "self-aware" is described in detail in Sec.~\ref{Sec:Self-Awareness}}~\cite{KoBrHuRe2010-SCC-Towards,Ko2011-SE-DescartesResearch} during operation ensuring that system quality-of-service requirements are continuously satisfied while infrastructure resources are utilized as efficiently as possible. The term Quality-of-Service (QoS) is used to refer to non-functional system properties including performance (considering classical metrics such as response time, throughput, scalability and efficiency) and dependability (considering in addition: availability, reliability and security aspects). The current version of \gls{dml} is focused on performance and availability including capacity, responsiveness and resource efficiency aspects, however, work is underway to provide support for modeling further QoS properties. The meta-model itself is designed in a generic fashion and is intended to eventually support the full spectrum of QoS properties mentioned above. Given that the initial version of \gls{dml} is focussed on performance, in the rest of this document, we mostly speak of performance instead of QoS in general. Information on the latest developments around the \acrfull{dml} can be found at \url{http://www.descartes-research.net}.
%architecture-level performance model to describe the service behavior and the resource landscape of modern distributed virtualized data centers.
% 1. Eingrenzung des Forschungsbereichs (In welchem Themengebiet ist die Arbeit angesiedelt? Wie ist das Verhältnis zum Thema der Konferenz/des Journals?)
......@@ -72,8 +71,7 @@ At run-time, the complete system now exists and a strict separation and encapsul
\paragraph{Type and Amount of Data Available for Model Parameterization and Calibration}
Performance models typically have multiple parameters such as workload profile parameters (workload mix and workload intensity), resource demands, branch probabilities and loop iteration frequencies. The type and amount of data available as a basis for model parameterization and calibration at design-time vs. run-time greatly differs.
Performance models typically have multiple parameters such as workload profile parameters (workload mix and workload intensity), resource demands, branch probabilities and loop iteration frequencies. The type and amount of data available as a basis for model parameterization and calibration at design-time vs. run-time greatly differs.\medskip
At design-time, model parameters are often estimated based on analytical models or measurements if implementations of the system components exist. One the one hand, there is more flexibility since in a controlled testing environment, one could conduct arbitrary experiments under different settings to evaluate parameter dependencies. On the other hand, possibilities for experimentation are limited since often not all system components are implemented yet, or some of them might only be available as a prototype. Moreover, even if stable implementations exist, measurements are conducted in a testing environment that is usually much smaller and may differ significantly from the target production environment. Thus, while at design-time, one has complete flexibility to run experiments, parameter estimation is limited by the inavailability of a realistic production-like testing environment and the typical lack of complete implementations of all system components.
At run-time, all system components are implemented and deployed in the target production environment. This makes it possible to obtain much more accurate estimates of the various model parameters taking into account the real execution environment. Moreover, model parameters can be continuously calibrated to iteratively refine their accuracy. Furthermore, performance-relevant information can be monitored and described at the component instance level, not only at the type level as typical for design-time models. However, during operation, we don't have the possibility to run arbitrary experiments since the system is in production and is used by real customers placing requests. In such a setting, monitoring has to be handled with care, keeping the monitoring overhead within limits (non-intrusive approach) such that system operation is not disturbed. Thus, at run-time, while theoretically much more accurate estimates of model parameters can be obtained, one has less control over the system to run experiments and monitoring must be performed with care in a non-intrusive manner.
......
......@@ -180,11 +180,11 @@ In summary, it is important to support the modeling of service behavior at diffe
To provide maximum flexibility, for each provided service, our proposed meta-model supports having multiple (possibly co-existing) behavior abstractions at different levels of granularity:
\begin{itemize}
\item {\bf Black-box behavior abstraction.} A ``black-box" abstraction is a probabilistic representation of the service response time behavior. Resource demands are not specified. This representation captures the view of the service behavior from the perspective of a service consumer without any additional information about the service's behavior.
\item {\textbf Black-box behavior abstraction.} A ``black-box" abstraction is a probabilistic representation of the service response time behavior. Resource demands are not specified. This representation captures the view of the service behavior from the perspective of a service consumer without any additional information about the service's behavior.
\item {\bf Coarse-grained behavior abstraction.} A ``coarse-grained" abstraction captures the service behavior when observed from the outside at the component's boundaries. It consists of a description of the frequency of external service calls and the overall service resource demands. Information about the service's total resource consumption and information about external calls made by the service is required, however, no information about the service's internal control flow is assumed.
\item {\textbf Coarse-grained behavior abstraction.} A ``coarse-grained" abstraction captures the service behavior when observed from the outside at the component's boundaries. It consists of a description of the frequency of external service calls and the overall service resource demands. Information about the service's total resource consumption and information about external calls made by the service is required, however, no information about the service's internal control flow is assumed.
\item {\bf Fine-grained behavior abstraction.} A ``fine-grained" abstraction captures the performance-rele\-vant service control flow which is an abstraction of the actual control flow. Performance-relevant actions are component-internal computational tasks, the acquisition and release of locks, as well as external service calls, thus also loops and branches where external services are called. Furthermore, the ordering of external service calls and internal computations may have an influence on the service performance.
\item {\textbf Fine-grained behavior abstraction.} A ``fine-grained" abstraction captures the performance-rele\-vant service control flow which is an abstraction of the actual control flow. Performance-relevant actions are component-internal computational tasks, the acquisition and release of locks, as well as external service calls, thus also loops and branches where external services are called. Furthermore, the ordering of external service calls and internal computations may have an influence on the service performance.
The control flow is modeled at the same abstraction level as the \gls{rdseff} of \gls{pcm} (cf.~\cite{becker2008a}), however, there are significant differences in the way model variables and parameter dependencies are modeled. The details of these are presented in Section~\ref{chap:systemarchitecture:sec:application:sec:parameterization} and Section~\ref{chap:systemarchitecture:sec:application:sec:probdependencies}. In contrast to the coarse-grained behavior description, a fine-grained behavior description requires information about the internal performance-relevant service control flow including information about the resource consumption of internal service actions.
\end{itemize}
......@@ -324,7 +324,7 @@ There are two ways to characterize the mentioned model variables. Either \model{
\model{EMPIRICAL} means that the model variable has to be quantified using monitoring statistics, i.e., it is characterized using empirical data that is accessed via an interface to the monitoring infrastructure. The interface is presented in Section~\ref{chap:systemarchitecture:sec:application:sec:monitoringinterface}.
\model{EXPLICIT} means that the model variable is characterized explicitly. In this case, an \model{ExplicitDescription} can be used to specify a random variable by means of the \gls{stoex} language proposed by~\cite{koziolek2008,becker2008a}. The \gls{stoex} language allows characterizing discrete probability distributions with \glspl{pmf}, approximating continuous probability densities with samples, or using common probability distribution functions such as the exponential distribution or the binomial distribution. Furthermore, the expression language allows specifying random variables ``as a combination of several other random variables using arithmetic or boolean operations''~\cite[p.66]{koziolek2008}.
The model variables \model{LoopIterationCount} and \model{CallFrequency} are discrete random variables defined on the sample space $\Omega = \mathbb{N}_0 = \mathbb{N} \cup {\{0\}}$. A typical \gls{pmf} for a loop is described, e.g., with the expression \texttt{IntPMF[(9;0.2)(10;0.5)(11;0.3)]}. This \gls{pmf} expressed as \gls{stoex} specifies that the loop body is executed 9 times with a probability of 0.2, 10 times with a probability of 0.5, and 11 times with a probability of 0.3.
The model variables \model{LoopIterationCount} and \model{CallFrequency} are discrete random variables defined on the sample space $\Omega = \mathbb{N}_0 = \mathbb{N} \cup {\{0\}}$. A typical \gls{pmf} for a loop is described, e.g., with the expression \texttt{IntPMF [ (9;0.2) (10;0.5) (11;0.3) ]} . This \gls{pmf} expressed as \gls{stoex} specifies that the loop body is executed 9 times with a probability of 0.2, 10 times with a probability of 0.5, and 11 times with a probability of 0.3.
Model parameter \model{BranchingProbabilities} is also described with a discrete random variable, however, its sample space $\Omega$ is the set of branch transitions of the corresponding \model{BranchAction}. The branch transitions are ordered, thus we can use their indexes as identifiers. A \gls{pmf} for the branching probabilities of a branch with two branch transitions is, e.g, \texttt{EnumPMF[(`Branch1';0.2)(`Branch2';} \texttt{0.8)]}, meaning that the transition with index 1 has a probability of 0.2, the transition with index 2 has a probability of 0.8.
The random variables of the remaining two model variables \model{ResponseTime} and \model{ResourceDemand} are typically defined on the sample space $\Omega = \mathbb{R}_{\geq 0}$, where $\omega \in \Omega$ is interpreted as timing value. They are described by a \gls{pdf} that is either approximated (see \cite[p.67]{koziolek2008} for an illustration) or defined using common distributions such as the exponential distribution.
......@@ -361,7 +361,7 @@ evalscope^v(\{a_1,\ldots,a_m\}) \\
\end{cases}
\end{array}
$$
Measurements of model variable $v$ at instance $\{a_1,\ldots,a_m\}$ are then valid within $evalscope^v(\{a_1,\ldots,a_m\})$.
Measurements of model variable $v$ at instance $\{a_1,\ldots,a_m\}$ are then valid within $evalscope^v(\{a_1,\ldots,a_m\\\})$.
Function $evalscope^v(\{a_1,\ldots,a_m\})$ evaluates to a (composite) component or (sub-)system instance whose type is in the set $S^{v}_0$, namely
the innermost instance when traversing from the instance identified by $\{a_1,\ldots,a_m\}$ to the system $s_0$.
Note that the scope of a variable is only considered if \model{EMPIRICAL} is chosen as a characterization type.
......@@ -559,9 +559,9 @@ As example for parameter dependencies, we use the parameter dependencies as they
\end{figure}
An excerpt of the object diagram is shown in Figure~\ref{fig:m-example_webshop_parameterdependency_cache_objectdiag}. There is a shadow parameter named \instance{articleAccessFrequency}, also attached to the service behavior abstraction of service \instance{getArticlePreviewImage}. The shadow parameter and the influenced variable are linked using a \model{DependencyRelationship}. The type of the \model{RelationshipCharacterization} is set to \model{EMPIRICAL}. The parameter \instance{pagenumber} of service \instance{listArticles}, provided by component \instance{CatalogServlet}, is exposed as another \model{InfluencingParameter}. Then there is a \model{DependencyPropagationRelationship} with parameter \instance{pagenumber} as independent parameter and the \instance{articleAccessFrequency} parameter as dependent parameter. This \model{DependencyPropagationRelationship} is also characterized with type \model{EMPIRICAL}.
\model{ShadowParameter} \instance{articleAccessFrequency} cannot be directly monitored. Thus, the \model{DependencyPropagationRelationship} and the \model{DependencyRelationship} cannot be characterized separately. The two relationships rather indicate that there is a dependency between service input parameter \instance{pagenumber} and the branching probabilities of cache hit or miss.
\model{ShadowParameter} \instance{articleAccessFrequency} cannot be directly monitored. Thus, the \model{Dependency-\\PropagationRelationship} and the \model{DependencyRelationship} cannot be characterized separately. The two relationships rather indicate that there is a dependency between service input parameter \instance{pagenumber} and the branching probabilities of cache hit or miss.
Figure~\ref{fig:m-example_webshop_parameterdependency_pagenumber_cache_histogram} shows exemplary monitoring statistics showing how values of parameter \instance{pagenumber} ranging from 1 to 12 relate to the probability of a cache miss. For instance, for a \instance{pagenumber} of 4, the probability of a cache miss is monitored to be 0.23 on average. Thus, for a \instance{pagenumber} of 4, the \model{BranchingProbabilities} can be parameterized with \texttt{EnumPMF[(`Branch1';0.77)(`Branch2';0.23)]} as \gls{pmf}. For a \instance{pagenumber} of 8, the probability of a cache miss is monitored to be 0.9 on average, and the \model{BranchingProbabilities} can be parameterized with \texttt{EnumPMF[(`Branch1';0.1)(`Branch2';0.9)]} as \gls{pmf}.
Figure~\ref{fig:m-example_webshop_parameterdependency_pagenumber_cache_histogram} shows exemplary monitoring statistics showing how values of parameter \instance{pagenumber} ranging from 1 to 12 relate to the probability of a cache miss. For instance, for a \instance{pagenumber} of 4, the probability of a cache miss is monitored to be 0.23 on average. Thus, for a \instance{pagenumber} of 4, the \model{BranchingProbabilities} can be parameterized with \texttt{EnumPMF[(`Branch1';0.77)(`Branch2';0.23)]} as \gls{pmf}. For a \instance{pagenumber} of 8, the probability of a cache miss is monitored to be 0.9 on average, and the \model{BranchingProbabilities} can be parameterized with \texttt{EnumPMF[(`Branch1';0.1)(`Branch2'\\;0.9)]} as \gls{pmf}.
\begin{figure}
\centering
\includegraphics[width=0.7\linewidth]{application_level_model/m-example_webshop_parameterdependency_pagenumber_cache_histogram}
......
......@@ -49,7 +49,7 @@ As shown on the diagram, the system under test (SUT) spans both the Java applica
We implemented the described scenario in the experimental environment depicted in Figure~\ref{fig:scen_overview}. As virtualization layer, we used the Xen Cloud Platform\footnote{The Xen Cloud Platform, \url{http://www.xen.org/products/cloudxen.html}}, an open source infrastructure platform that provides standard resource management functionality as well as additional features such as high availability or management facilities based on standardized APIs. It is based on the Xen hypervisor by Citrix which is one of the major virtualization platforms used in industry.\forget{ Using an open source platform eases the publication of measurements with the benchmark as well as accessing the source code, if necessary.} For the deployment of the application server tier, we used Oracle WebLogic Server (WLS)~10.3.3 instances. Each WLS instance runs on a machine with 2x4-core Intel CPUs with OpenSuse~11.1. As database server~(DBS), we used Oracle Database 11g, running on a 24-core Dell~PowerEdge~R904. The benchmark driver and the supplier emulator were running on virtualized blade servers. The machines are connected by a 1~GBit~LAN. The presented environment can be considered as representative of a modern business information system.
For each customer in our scenario, a separate instance of the benchmark is deployed in one application server cluster assigned to the respective customer. The customer's workload is generated by a customized instance of the benchmark driver. The operations executed by the \SjE{} benchmark are {\tt Browse, Purchase, Manage, CreateVehicleEJB} and \texttt{CreateVehicleWS}. As an example of an SLA, the customer could require that the response time of {\tt Purchase} must not exceed 5$ms$ or, less restrictive, must be below 5$ms$ in 95\% of the cases within a given time horizon (e.g.,~one hour).
For each customer in our scenario, a separate instance of the benchmark is deployed in one application server cluster assigned to the respective customer. The customer's workload is generated by a customized instance of the benchmark driver. The operations executed by the \SjE{} benchmark are {\texttt Browse, Purchase, Manage, CreateVehicleEJB} and \texttt{CreateVehicleWS}. As an example of an SLA, the customer could require that the response time of {\texttt Purchase} must not exceed 5$ms$ or, less restrictive, must be below 5$ms$ in 95\% of the cases within a given time horizon (e.g.,~one hour).
\forget{The scenario will also consider load-balancing of a customer's workload among several application servers. The Oracle WebLogic application server provides such possibilities for clustering. Hence, several application servers on different machines will be combined to an application server cluster. Adding an additional application server to the cluster is, e.g., one possible solution to handle increasing workload. Additionally, virtualization provides facilities for dynamic re-allocation of resources or redeployment of services, e.g., VCPU allocation or LiveMigration. These reconfiguration options will be targeted in further extensions of this scenario.
......
......@@ -7,7 +7,7 @@
\usepackage[scaled=.92]{helvet}
% auskommentiert, weil ich die scheiss Schriftart nicht installiert bekomme (Fabian)
%\usepackage[scaled]{luximono}
\usepackage{microtype}
\usepackage{amsthm}
\usepackage{graphicx} % include graphics
%\usepackage[pdftex]{graphics} % include pdf graphics in LaTeX
......@@ -76,13 +76,13 @@
%no chapter numbers in title
\renewcommand*{\chaptermarkformat}{}
\renewcommand*{\sectionmarkformat}{}
\usepackage{etoolbox}
\apptocmd{\sloppy}{\hbadness 10000\relax}{}{}
%no page numbers on chapter title pages
\renewcommand*{\chapterpagestyle}{empty}
\vbadness=10000
%fonts
\setkomafont{subparagraph}{\small}
%\parindent 0pt
%Mathematical Symbols
......@@ -91,6 +91,11 @@
\newcommand{\strongereq}{\trianglerighteq}
\newcommand{\stronger}{\vartriangleright}
\usepackage{scrhack}
%see http://tex.stackexchange.com/questions/76273/multiple-pdfs-with-page-group-included-in-a-single-page-warning
\pdfsuppresswarningpagegroup=1
%Glossary
\usepackage{nomencl}
\let\abbrev\nomenclature
......@@ -109,7 +114,7 @@
%\textcolor{OliveGreen}{\emph{stable}}
%\newline
}
\pretolerance=1000
\newcommand{\nearlystable}{
%\textcolor{BurntOrange}{\emph{nearlystable}}
%\newline
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment