Les performances se mesurent classiquement selon deux axes : la capacité à traiter un volume important de transitions et le temps de réponse (la latence). Dans une utilisation sur un bus asynchrone, on se concentre plus sur le premier point, car la latence est liée au throughput (cf. Queueing formulas).
En revanche, pour la synchronisation de services synchrones, la latence est vraiment un point important, en particulier si le protocole de gestion des erreurs implique une augmentation du nombre d’allers-retours entre le moteur de processus et les composants.
Faire un dessin avec une grosse queue et une petite pour le meme débit 7/1 vs 1/1
Point clé: loi fondamentale – vrai dans toutes les situations – mais ne décrit pas l’état (qui est fortement lié à la distribution)
Montrer que T (traitement) = W (attente) + 1/lambda (processing)
La dernière ligne est le point clé.
Lambda = taux d’arrivée
Mu = taux de traitement
M = poisson
K = nombre de jobs en attente
CB = coefficient de variation = écart-type sur moyenne
Fw = distribution des temps d’attente
Pi_k = proba d’avoir k jobs dans le système
Pi_k = pi0(m ro) ^k / k! si k < m et pi0 ro^k m^m / m! sinon
Figure 6.4 shows that the mean number of jobs increases with the number of serverm (constant utilization) but mean Q decreases
Q = queue length
cd. QN and Mark. Chain, p219
Cf Chapitre 15 de « Performance by design » : Non-product form queueing models
-> resource contention, blocking, forking & synchronization, priority scheduling
Idée clé du lean – 6 sigma : la variation de mu d’un système devient la variation lambda du second
Cf OAI experiments
1er tableau = respect SLA
2e = temps de traversée moyen
Chaos = augmentation de la déviation
Burst = 1h d’augmentation de traffic
Quick = short burst
SLA = fonction de la déviation ! Montre que plus de serveurs réduisent la stdev
Slide clé
IO est soucvent un bottleneck car pas toujours parallèle (locks)
Liens avec archi de données !
Comme nous l’avons dit précédemment, l’utilisation combinée de communication synchrones et asynchrones est obligatoire dans la pratique, mais il faut alors insister sur deux objectifs :
partager les services, et éviter de construire un double jeu d’interfaces, un pour les appels synchrones et un pour les appels asynchrones.
construire un modèle commun de performance, puisque la plupart des composants vont rendre des services dans les deux modes synchrones et asynchrones à partir des mêmes cycles CPU.
L’expérience de Bouygues Telecom est que ces deux objectifs, et en particulier le premier, sont difficiles. Nous allons y revenir dans le chapitre 7 en proposant un modèle unifié pour l’intégration d’applications.
Exemples tirés de mon expérience Bytel
Cf. p.48 de « Performance by Design » : # of thread du DBMS = compromis entre software contention (beaucoup de threads) et physical contention (peu de threads)
XML Pull Parsing is touted as a high performance alternative to DOM for XML parsing that is easier to use than SAX. SAX is push API and enjoys wide spread adoption virtually removing any other push API in Java. This is not the case for pull parsing where many APIs were created and only recently JSR 172 StAX (Streaming API for XML) promises to provide one standard. However even if StAX will become the API for pull parsing it is important to understand choices made in API, especially dual nature of StAX API. Additionally when choosing XML processing API between tree oriented (such as DOM), streaming push (SAX) and pull (StAX) it is crucial to understand limitations of each approach and in particular trade-off between easiness of use and memory utilization/performance.
StAX: https://sjsxp.dev.java.net/
The Streaming API for XML (StAX) is the new generation of XML APIs in Java. StAX is based on the so-called pull model in which an application queries the parser for the next parsing event, but never surrenders control to the parser during the process. Stated differently, StAX essentially turns the SAX processing model upside down. Instead of the parser controlling the application's flow, and the application reacting to parsing events, it is the application that controls the flow by pulling events from the parser.
This parsing model has several advantages over SAX. First, it often makes the application logic easier to understand given that it is the application and not the parser that is in control of the process (stated differently, the application does not get "pushed around" :). Second, if implemented correctly, there are a number of new optimizations that are possible when the application does not need to process the entire infoset. In particular, it is possible to lazily wait until the application requests a certain infoset item before it is actually constructed (a good example of this is lazy creation of Java strings).
Both StAX and SAX work in streaming fashion and allow only forward reading. However, the StAX model gives the application a lot more control: for example, applications have the option of pausing and resuming the parsing process, skipping over unneeded content, etc. For further information please refer to the Java Web Services Tutorial.
The StAX cursor model (XMLStreamReader) is the most efficient way to parse XML since it provide a natural interface by which the parser can compute values lazily. SJSXP takes full advantage of this by delaying the creation of certain objects until they are needed. SJSXP's XML token scanner is based on Xerces 2 but has been modified to accomodate the new pull model. The result is an implementation that is fully complaint with the XML specifications while at the same time offering very good performance.
Amdhal’s law – cf. Guerilla warfare
S(p) = p / (1 + s(p – 1)) s = serial fraction
S(p) = coefficient de speed-up avec p processeur
S = % du travail non parralélisable
Ex: 10% => asymptote = 10
Cf. Performance by Design p. 16 = trashing = la courbe decroit si le load est trop important
Wikipedia:
Un serveur d'applications est un serveur qui centralise toutes les applications utilisées par les postes clients. Les applications sont chargées sur le serveur tandis que leurs IHM (Interfaces Hommes-Machines) sont distribuées sur les postes clients. Dans une infrastructure N-tiers régulière, on peut déployer plusieurs serveurs d'applications, que ce soit pour répartir la charge lorsque le nombre élevé de postes clients est une exigence critique, ou que ce soit simplement pour les redonder lorsque leur disponibilité est aussi une exigence critique (les dispositifs de redondance peuvent être plus ou moins sophistiqués suivant qu'ils garantissent des temps de reprise en secours plus ou moins brefs, i.e. une disponibilité de service plus ou moins continue).
Le serveur d'applications agit comme tout serveur, il prend la requête du poste client, exécute les traitements à effectuer et retourne le résultat au poste client. Ce faisant, il assure la persistance des données au cours et entre plusieurs transactions d'un même poste client, ainsi que la persistance des données partagées et les arbitrages d'accès entre plusieurs postes clients concurrents.
Les serveurs d'applications sont des logiciels occupant la couche centrale dans une architecture multicouche, qu'elle soit classique 3-tiers (postes clients, serveur de données, serveur d'applications) ou étendue (n-tiers) lorsqu'elle intègre des serveurs d'acquisition (données de terrain, données de process, de back-office, etc.) et/ou des serveurs d'interface (gateways, systèmes coopérants externes, etc.).
www.labon-sun.com:
Le serveur d'application est l'environnement d'exécution des applications côté serveur. Il prend en charge l'ensemble des fonctionnalités qui permettent à N clients d'utiliser une même application :Gestion de la session utilisateur : N clients utilisant une même instance d'application sur le serveur, il est nécessaire que le serveur d'application puisse conserver des contextes propres à chaque utilisateur (par exemple, un panier de commandes). La plupart des serveurs d'application génèrent un identifiant unique pour chaque nouveau client et transmettent cet identifiant lors de chaque échange HTTP par URL longs, variables cachées ou cookies.
Gestion des montées en charge et reprise sur incident : Afin de gérer toujours plus d'utilisateurs, le serveur d'application doit pouvoir se déployer sur plusieurs machines et éventuellement offrir des possibilités de reprise sur incident (même si dans la grande majorité des cas, on se contente d'une gestion des montées en charge au niveau réseau - boîtier de répartition, DNS round-robin, reverse proxy ...).
Ouverture sur de multiples sources de données : C'est le serveur d'application qui rend accessible les données des applications du système d'information. Il doit donc pouvoir accéder à de nombreuses sources de données. On s'attend également à ce qu'il fournisse des mécanismes performants comme le pooling de connexion base de données.
...
Le serveur d'application est donc indispensable si l'on souhaite éviter de re-développer l'ensemble de ces fonctionnalités (cas des GGI). Les moteurs JSP/Servlets, Microsoft ASP, Cold Fusion, PHP ... sont à ce titre des serveurs d'application (même si il sont intégrés au ServeurWeb PHP/ASP).
Mon expérience
Nous avons trop tiré vers l’optimisation 80%
Nous nous sommes toujours trompé sur la capacité à optimiser
Savoir ce qui tourne sur les machines : lien avec le monitoring !
La qualité de service (QoS) est l’objectif fondamental du DSI d’un opérateur de télécommunication
La Qualité de service est définie et mesurée à partir des processus métiers, ce qui motive l’orientation-processus du système d’information
La QoS est formalisée au moyen de SLA (Service Level Agreement)
Débit: un flux de 3000 nouvelles activations par jour
Délai: le temps qu’il faut pour traiter une nouvelle activation de bout-en-bout
Exemple: moins de 4h dans 80% des cas, moins de 12h dans 99%.
Disponibilité: % du temps 7/24 pendant lequel le service est disponible
Anecdote: White Pajama, Call centers en ASP
Centre d’appel, 3 catégories : gold, silver and bronze
QoS garantie: appel pris en moins de 10s, 30s, 120s.
Problème ouvert, sous-ensemble de l’OAI