Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "VIATRA2/Examples/performability analysis"
(→Performability model) |
m (format updates) |
||
| Line 1: | Line 1: | ||
| − | == Description == | + | == Description == |
| − | This example shows a method for a model-driven performability analysis of reliable systems so that the cost of reliability can be assessed without realizing the whole system. | + | This example shows a method for a model-driven performability analysis of reliable systems so that the cost of reliability can be assessed without realizing the whole system. The word performability comes from performance and availability. Performance analysis aims at measuring the cost of dependability, i.e. the performance overhead introduced by using reliable middle-ware. |
| − | The word performability comes from performance and availability. Performance analysis aims at measuring the cost of dependability, i.e. the performance overhead introduced by using reliable middle-ware. | + | |
| − | == Overview of the process == | + | == Overview of the process == |
| − | Starting from UML component diagrams and non-functional descriptions of services, a platform independent service model (SOA-PIM) is generated, on which performability analysis is carried out by deriving process models for PEPA Toolkit. | + | Starting from UML component diagrams and non-functional descriptions of services, a platform independent service model (SOA-PIM) is generated, on which performability analysis is carried out by deriving process models for PEPA Toolkit. [[Image:Toolchain.png]] |
| − | [[Image: | + | |
| − | == UML models == | + | == UML models == |
| − | From the point of view of the analysis the relevant part of the UML diagrams is illustrated in the following Figure. | + | From the point of view of the analysis the relevant part of the UML diagrams is illustrated in the following Figure. |
| − | [[Image: | + | [[Image:Pepa cases.png]] |
| − | This model specifies to use reliable messaging middle-ware between Vehicle Communication Interface a BankCharge Component. The system engineer who sets the values of the parameters (inactivityTimeout, exponentialBackoff etc.) can make a model-driven performability analysis to find out the cost of reliability which can be compared to the result of performance analysis. | + | This model specifies to use reliable messaging middle-ware between Vehicle Communication Interface a BankCharge Component. The system engineer who sets the values of the parameters (inactivityTimeout, exponentialBackoff etc.) can make a model-driven performability analysis to find out the cost of reliability which can be compared to the result of performance analysis. |
| − | == Performability model == | + | == Performability model == |
| + | The next Figure shows the stochastic model of a service configuration with at-least-once messaging semantics. (Every message is transmitted at least once with possibility of having multiply instances of the same message.) | ||
| − | + | [[Image:PerformanceModel.png]] | |
| − | + | The two automates represents the behavior of a reliable messaging server and client. The one on the left is the server which has two states (rectangles on the figure): processing a request or waiting for a new one. As a new message arrives (?send), the state of the server changes to processing. After finishing processing, the server sends (!ack) acknowledgment message to the client. (! stands for sending a message and ? means receiving an incoming message. The client is behaving according to at-least-once semantics so the request is resent upon internal timeout events occur until acknowledgment message is received. To avoid infinite working, an upper limit is set on the number of retransmissions (retransmission number). If an acknowledgment arrives, the message transmission is considered successful. Sending and receiving messages (send, resend, ack) is carried out by synchronization between the two processes. | |
| − | + | == Model parameters == | |
| − | + | ||
| − | + | ||
| − | == Model parameters == | + | |
Non-functional parameters of services are used to derive send, resend and acknowledgement rates. These parameters come from UML models shown above. | Non-functional parameters of services are used to derive send, resend and acknowledgement rates. These parameters come from UML models shown above. | ||
| − | For example: | + | For example: |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | '''inactivityTimeout''': after this period of time in no acknowl- edgment message has arrived connection is closed; | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | '''retransmissionInterval''': after this time resend request is sent by client. | |
| − | + | From these parameters retransmission number can be derived: | |
| + | [[Image:Retransmission.png]] | ||
| − | + | == Transformation result == | |
| − | + | After performing the chain of transformations, pepa code is generated: | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | //Rates | |
| + | rateTransmit=1.0; | ||
| + | rateAck=0.3; | ||
| + | rateTimeout=0.4; | ||
| + | rateReset=8.0; | ||
| + | //Definitions | ||
| + | BankChargeIdle=(send, infty).Processing; | ||
| + | Processing=(ack, rateAck).BankChargeIdle + (resend, infty).Processing; | ||
| + | VehicleCommunicationIdle=(send, rateTransmit).MsgSent1; | ||
| + | MsgSent1=(ack, infty).Success + (timeout, rateTimeout).Failed1; | ||
| + | Failed1=(resend, rateTransmit).MsgSent2; | ||
| + | MsgSent2=(ack, infty).Success + (timeout, rateTimeout).Failed2; | ||
| + | Failed2=(resend, rateTransmit).MsgSent3; | ||
| + | MsgSent3=(ack, infty).Success + (timeout, rateTimeout).Failure; | ||
| + | Failure=(ack, infty).VehicleCommunicationIdle; | ||
| + | Success=(reset, rateReset).VehicleCommunicationIdle; | ||
| + | //Equation | ||
| + | BankChargeIdle[1] < send, resend, ack > VehicleCommunicationIdle[1] | ||
Revision as of 12:54, 19 March 2010
Contents
Description
This example shows a method for a model-driven performability analysis of reliable systems so that the cost of reliability can be assessed without realizing the whole system. The word performability comes from performance and availability. Performance analysis aims at measuring the cost of dependability, i.e. the performance overhead introduced by using reliable middle-ware.
Overview of the process
Starting from UML component diagrams and non-functional descriptions of services, a platform independent service model (SOA-PIM) is generated, on which performability analysis is carried out by deriving process models for PEPA Toolkit. 
UML models
From the point of view of the analysis the relevant part of the UML diagrams is illustrated in the following Figure.
This model specifies to use reliable messaging middle-ware between Vehicle Communication Interface a BankCharge Component. The system engineer who sets the values of the parameters (inactivityTimeout, exponentialBackoff etc.) can make a model-driven performability analysis to find out the cost of reliability which can be compared to the result of performance analysis.
Performability model
The next Figure shows the stochastic model of a service configuration with at-least-once messaging semantics. (Every message is transmitted at least once with possibility of having multiply instances of the same message.)
The two automates represents the behavior of a reliable messaging server and client. The one on the left is the server which has two states (rectangles on the figure): processing a request or waiting for a new one. As a new message arrives (?send), the state of the server changes to processing. After finishing processing, the server sends (!ack) acknowledgment message to the client. (! stands for sending a message and ? means receiving an incoming message. The client is behaving according to at-least-once semantics so the request is resent upon internal timeout events occur until acknowledgment message is received. To avoid infinite working, an upper limit is set on the number of retransmissions (retransmission number). If an acknowledgment arrives, the message transmission is considered successful. Sending and receiving messages (send, resend, ack) is carried out by synchronization between the two processes.
Model parameters
Non-functional parameters of services are used to derive send, resend and acknowledgement rates. These parameters come from UML models shown above.
For example:
inactivityTimeout: after this period of time in no acknowl- edgment message has arrived connection is closed;
retransmissionInterval: after this time resend request is sent by client.
From these parameters retransmission number can be derived:
Transformation result
After performing the chain of transformations, pepa code is generated:
//Rates rateTransmit=1.0; rateAck=0.3; rateTimeout=0.4; rateReset=8.0; //Definitions BankChargeIdle=(send, infty).Processing; Processing=(ack, rateAck).BankChargeIdle + (resend, infty).Processing; VehicleCommunicationIdle=(send, rateTransmit).MsgSent1; MsgSent1=(ack, infty).Success + (timeout, rateTimeout).Failed1; Failed1=(resend, rateTransmit).MsgSent2; MsgSent2=(ack, infty).Success + (timeout, rateTimeout).Failed2; Failed2=(resend, rateTransmit).MsgSent3; MsgSent3=(ack, infty).Success + (timeout, rateTimeout).Failure; Failure=(ack, infty).VehicleCommunicationIdle; Success=(reset, rateReset).VehicleCommunicationIdle; //Equation BankChargeIdle[1] < send, resend, ack > VehicleCommunicationIdle[1]