\section{Databases Performance Model} \label{Model}

This section describes our proposal for modeling and performance evaluation of DB performing in Service-oriented environments. 
We are considering the flow of requests since their departure from the web service to the DB server, until a response is received back, by the web service. 
Alternatively, additional analysis of the SOA process could be associated to the present proposal, covering network links, orchestrations engine and web service evaluations \cite{Teixeira2009} \cite{Teixeira2010}.  

The sequence diagram presented in Fig.~\ref{imgUMLScenario} identifies our workspace within a SOA-aware scenario.
%###################################
\begin{figure}[h]
         \centering
        \includegraphics[height=5.7cm, width=14cm]{IMG/UMLScenario.png}
         \caption{Typical SOA Process Interaction}
         \label{imgUMLScenario}
\end{figure}
%################################### 

Usually, a web interface is used to compose packages sent from remote users to a BPEL server. 
After received, the messages are orchestrated by the BPEL's engine, that invokes several distributed WS iteratively, until a response be sent to requestors. 
Usually, web services operations require databases transactions (in bold), whose performance evaluation is our goal. 

Based on the scenario from Fig.~\ref{imgUMLScenario}, we identify which ranks of activities and devices are responsible for time consumption in a DB transaction, such that the following delays are considered:
\begin{itemize}
    \item Buffering: it is responsible for storing messages, before and after the DB execution; 
    \item Parsing: corresponds to the stage of validation, syntactical and semantical, of the queries received for processing into DB server;
    \item Execution: consists in to perform the validated code. This stage involves accessing the data relations, building a package that answers each request.  
\end{itemize}

From a stochastic point of view, {\em Parsing} and {\em Execution} stages could be evaluate together, since the largest portion of time is consumed by the "execution" rank. 
Hence, in Fig.~\ref{imgDBModel} we present the proposed general structure to map the temporal behavior of DB transactions. %Fig.~\ref{imgDBModel} (b) depicts the probability function adopted in this paper, by reasons discussed in Section \ref{Case}. 
The models building embodies the GSPN (Generalized Stochastic Petri Nets) formalism as modeling technique and composition rules among them. 
Thus, it can be simulated through specific tools (e.g. TimeNet~\cite{Timenet2011}) and performance metrics can be obtained. 
%###################################
\begin{figure}[h]
         \centering
        \includegraphics[height=6.4cm, width=15cm]{IMG/Model/DBModel.png}
         \caption{Proposed GSPN structure for Databases Performance Evaluation.}
         \label{imgDBModel}
\end{figure}
%################################### 

Table \ref{Notation} presents the main notation for the model. Timely, we shall discuss how to assign the correspondent parameters (see in Subsection \ref{feed}). 

\begin{table}[h]
\centering
\caption{Notation for the Proposed Model.}
\begin{tabular}{|c|c|l|} \hline
\multicolumn{ 2}{|c|}{{\it {\bf Notation}}} & {\it {\bf Description}} \\ \hline \hline
\multicolumn{ 1}{|c|}{{\it {\bf }}} &   $Stat_i$ & 
Used only for estimates purposes. It holds the tokens from the start to the exit point; \\ \cline{2-3}
\multicolumn{ 1}{|c|}{{\it {\bf }}} &      $R_i$ & 
Contains the available resources for input queue (size in bytes); \\ \cline{2-3}
\multicolumn{ 1}{|c|}{{\it {\bf Places}}} &      $K_i$ & 
Contains the available execution resources (parallel processing); \\ \cline{2-3}
\multicolumn{ 1}{|c|}{{\it {\bf }}} &      $S_i$ & 
Contains the requests waiting for processing; \\ \cline{2-3}
\multicolumn{ 1}{|c|}{{\it {\bf }}} &     $QI_i$ & 
Contains the requests that are being processed; \\ \cline{2-3}
\multicolumn{ 1}{|c|}{{\it {\bf }}} &     $QO_i$ & 
Contains the requests after processing; \\ \hline \hline
\multicolumn{ 1}{|c|}{{\it {\bf }}} & $T\lambda_i$ & 
Simulates the arrival of requests in the system; \\ \cline{2-3}
\multicolumn{ 1}{|c|}{{\it {\bf Transitions}}} & $tI_{dbi}$ & 
Represents the DB processing Input; \\ \cline{2-3}
\multicolumn{ 1}{|c|}{{\it {\bf }}} & $tO_{dbi}$ & 
Represents the DB processing output; \\ \cline{2-3}
\multicolumn{ 1}{|c|}{{\it {\bf }}} & $t_{endi}$ & 
Simulates the process exit point. \\ \hline
\end{tabular}  
\label{Notation}
\end{table}


Let $i$ be the indexer of the evaluated DB\footnote{Several DBs could be concurrently evaluated in a Web Service Composition}. 
Basically, the model starts by firing the timed transition $T_{\lambda_i}$, according to rate $1/d_{\lambda_i}$, resulting from the delay $d_{\lambda_i}$. 
The fired requests are inserted into an input queue $QI_i$, bounded by the number of resources in the place $R_i$. 
According to the availability of resources in the place $K_i$, the transition $tI_{dbi}$ fires, inserting the request into the place $S_i$, which contains the requests that are being executed in the DB. 
Hence, the tokens remain in $S_i$ according to the adopted {\em Probability Mass Function - PMF} (gray block), whose choice is supported by measured DB statistics (see Section \ref{Concepts}). Timely we turn to discuss the PMF selection (See Section \ref{Case}).

After performing, the requests are inserted into the output queue $QO_i$, which represents also the model exit point. 
The supported number of requests in $QO_i$ is coordinated by the availability of resources in $R_i$ place. 
The weights of input and output arcs, from/to places $R_i$ and $K_i$, express the impact caused by inserting and removing resources in each repository. This impact is conservative, that is, the number of removed and returned tokens is the same, for each request.

Notice that by sharing $R_i$ with $QI_i$ and $QO_i$ places, it is possible a model deadlock. 
Supposing, for example, a situation where $QI_i$ consumes all the resources from $R_i$. 
After perform, the requests can not be sent to $QO_i$, because there is no more resources for that. 
For the same reason, $T\lambda_i$ can not trigger requests toward $QI_i$. 
Therefore, the system is blocked. 

In order to avoid that, we assign conditions for the arcs {\em Case (i)} and {\em Case (ii)}. 
Through {\em Case (i)} we avoid the deadlock by firing of $tO_{dbi}$, even if there is no enough resources in $R_i$. 
When it happens, {\em Case (ii)} assigns $0$ for the arc that leads to $QO_i$, discarding definitively the request.




\subsection{Model Parameters}\label{feed}

In order to simulate the proposed model, it is necessary to feed its input structures. 
In the following, we presented a practical manner to do that.
%, guided by the notation presented in Table \ref{tab:ModelNotation}.


\subsubsection{Database Queue Parameters} 

Let $R_i$ be the available resources for the input and output DB queues occupation. 
The marking\footnote{"\#" is used to reference the number of tokens in the place $p$ ($\#p\in \mathbb{N}$).} 
of $R_i$ is defined according to the buffer size, measured in the real DB system. 
In practice, each DBMS defines their own parameters for the amount of memory available for DB operations. 
These parameters are flexible and can be changed according to the system management rules. 
The most important parameters to be collected from DBMS are:
\begin{enumerate}
    \item Number of Memory Pages ($NMP$) (integer): refers to the available number of memory blocks destined to serve the DB operations\footnote{Large database pages benefits database performance, usually decreasing I/O time.};  
    \item Size of the Memory Pages ($SMP$) (bytes): represents the amount of bytes assigned to each $NMP$. 
\end{enumerate}

From $M = NMP * SMP$, we have the amount of memory ($M$) available for storing input and output messages from/to DB system. 
Therefore, the marking of $R_i$ is such that $\#R_i = M$. 
In addition, one need to establish the impact caused by the arcs from/to $R_i$. 
For that, we assign weights to the arcs (a) $Get\_R_i$ and (b) $Put\_R_i$, according to the mean size of exchanged messages (bytes), such that:
$$
(a)~~Get\_R_i = Msg_{arr}; ~~~~~~~~~~ (b)~~Put\_R_i = Msg_{dep},
$$
where $Msg_{arr}$ and $Msg_{dep}$ are the measured mean size of messages arriving/departing, respectively, in/from DB system. 
Finally, the assigned parameters allow us to estimate the DB Queue Response Time (QRT), through the following equation: 
$$
QRT = 	\frac{E(QI_i) + E(QO_i)}{\lambda_i},
$$
where, for $j= QI_i, QO_i$, $E(j)$ corresponds to the expectation of tokens in the place $j$ and $\lambda_i$ is the arrival rate of requests in the DB $i$. 
Observe that $\lambda_i$ results from $1/d_{\lambda_i}$ and $d_{\lambda_i}$ is the parameter of the transition $T\lambda_i$. 
The QRT represents the overall time spent by messages waiting before and after their processing. 




\subsubsection{Database Execution Parameters} 
Modeling DB processing operations encompasses requests since their arrival, in the $S_i$ place, until that transition $tO_{dbi}$ fires. 
Therefore, the adopted PMF makes part of the DB execution modeling so as $K_i$, that contains the available resources for DB processing. In the following we show how to calculate these parameters.

\paragraph{Resources for Processing} 
In order to establish the marking of $K_i$, it is necessary to measure the DB system (or its prototype when it is not available for). 
Specifically, one must collect the maximum number of parallel operations supported by the DB, without causing queues on the system. 

Through gradually increasing the workload level, we observe the point where the queue appears on DB system. 
It is detected by an increase in the response time when the workload overcomes the resources available for processing. 
Thus, $\#K_i$ receives the value of the workload applied before observing the first signals of queue. 
The weight of the arcs $Get\_K_i$ and $Put\_K_i$ is $1$, since their source place ($K_i$) contains requests and, therefore, each performed request has impact $1$ on its resources repository.


\paragraph{Processing Response Time} 
These assigned parameters enable us to estimate the DB Processing Response Time (PRT), through the following equation:
$$
  PRT = \frac{E(S_i) + E(PMF)}{\lambda_i},
$$
where, $E(S_i)$ is the expectation of tokens in the place $S_i$ and $E(PMF)$ is the expectation of tokens in all the places contained in the $PMF$ structure. Finally, $\lambda_i$ is the arrival rate of requests in DB system $i$. 
The value of PRT represents the amount of time spent when processing DB operations. 


\subsubsection{Overall Database Response Time} 

Finally, one can estimate the overall DB Response Time (DBRT), including queues and processing time, according to one of the following equations: 
$$
DBRT = \frac{E(Stat_i)}{\lambda_i},~~~~ or~even ~~~~ DBRT = QRT + PRT,
$$ 
where $E(Stat_i)$ contains the expectation of tokens in the place $Stat_i$, which does not exert a functional role, but it is used for storing the overall process expectation. 
Hence, the value of $DBRT$ means the amount of time spent by a DB transaction, considering all its execution stages.

Summarizing, the proposed DB performance evaluation starts by receiving a set of parameters, without including any evidence of queue. 
As a result, we inform the variable behavior assumed by the DB system, insofar as the workload level increases. 
For that, of course, the GSPN must be simulated, as presented in the following.
