|
|
WWDC 2005 : optimisation WO
 |
    
La session était animée par 3 personnes avec par ordre d'apparition sur scène : Bill Bumgarner. Ravi Mendis et Max Muller. Bill Bumgarner, anciennement membre de la société Codefab, ne fait plus proprement parti de l'équipe de de développement WO mais "une fois qu'on a utilisé WO, on reste toujours développeur WO" expliqua t'il.
[Note du rapporteur : cette session était très dense en informations et ma vitesse de prise de notes était souvent insuffisante surtout la session présentée par Max Muller]
Intervention de Bill Bumgarner
Bill a fait un état des lieux des technologies web.
Qu'est ce qui a le plus évolué depuis ces dernières années ?- l'augmentation de la bande passante, aussi bien coté client que coté serveur
- le prix de la bande passante a fortement baissé, la aussi coté client et coté serveur
- HTML tend à se standardiser
Concernant l'HTM, Bill explique que si l'HTML a évolué (apparition des feuilles de style par exemple), il n'y a pas eu de changements majeurs. Par contre l'organisation et les fonctionnalités des sites web évoluent beaucoup :- le contenu est lié à l'environnement (dépend des preferences de l'utilisateurs, de ce qu'il a vu avant, ...)
- la personnalisation est plus poussée
- les systèmes s'intègrent de plus en plus (ex : Google Search)
D'autre part, l'HTML n'est plus la seule technologie utilisée pour restituer de l'information. D'autres alternatives se développent comme :
ou bien l'HTML est utilisé dans d'autres contextes, à tout le moins dans l'environnement Apple comme la doc Xcode ou bien Webkit.
En conclusion, les applications web génèrent du contenu dynamique en dehors du simple navigateur avec une complexité croissante (à noter que dynamique ne veut pas dire temps réel : en analysant les demandes, il est fortement recommandé de préparer à l'avance les contenus les plus demandés)
Bill ajoute un dernier point en expliquant que les systèmes sont de plus en plus complexes et qu'il est difficile de tout prévoir. En conséquence, il est nécessaire de mettre en place des instruments de mesure en environnement de production.
Intervention de Ravi Mendis
Ravi a articulé son intervention autour de l'explication de 3 objectifs concernant le design d'une application WO :- design de l'EOModel
- Exploiter la base de données
- minimiser l'empreinte mémoire
Design de l'EOModel- Augmenter la simplicité. Le re-engeniring est couteux car un EOModel est difficile à refaire et il est difficile de migrer les données. Donc il faut faire juste dès le départ
- Minimiser l'héritage (d'entités) car cela augmente le nombre de fetches (voir documentation EOF sur l'heritage horizontal, vertical, ...)
- En cas d'héritage, toujours dériver d'une classe abstraite
- Eviter l'héritage de plus d'un niveau
Par exemple, dans le muzicStore, il y a plus de 400 entités réparties dans 12 modèles et seules 5% des entités ont de l'héritage (à un seul niveau)
Exploiter la base de données- utiliser le rawRows pour avoir les resultats d'une recherche rapidement ou pouvoir faire des sous requetes. Ceci permet de manipuler des dictionnaires plus "légers" que des eo et d'optimiser les jointures. Le désaventage principal est d'avoir à convertir du rawRows en eo
- ne pas hésiter à utiliser des attributs dérivés pour modeliser des aggrégations comme count(*), max(xxx), min(yyy). Ceci permet de continuer de manipuler de eo (ne pas oublier de mettre l'attribut en read only et non verrouillé).
Ces techniques sont beaucoup utilisées dans le muzicStore
Minimiser l'empreinte mémoire- Ne pas hésiter à partitionner en plusieurs groupes de fonctionnalités et donc en plusieurs applications (par exemple, la saisie d'un CMS).
- Utiliser des DirectAction et fetcher les eo dans un local editingContext, local au composant. Ainsi, les eo sont détruits à la fin du cycle Requete/Reponse. Le corrolaire, c'est d'utiliser des variables de session avec parcimonie.
- Utiliser des composants stateless (gain important).
- Utiliser des shareEditingContext. Ceci permet le partage d'eo en lecture seule entre plusieurs sessions. Les shareEditingContext ont plusieurs avantages : ils sont thread safe et ils réduisent le traffic avec la BD. Plus de 40 entités sont gérées par un shareEditingContext dans le muzicStore.
En tout cas, en cas de pb, un des points clef est l'observation. Il faut détecter les goulots d'etranglement et utiliser le monitor pour analyser les WOStats et les WOEvents. Ne pas oublier de regarder les logs du serveur web.
Intervention de Max Muller
[C'est l'intervention la moins converte : information dense et qui nécessitait de réfléchir en meme temps ;-) Je la reprendrai lorsque la vidéo sera en ligne]
Pour rappel, Max Muller est un des fondateurs du projet ProjectWonder.
Son intervention a porté sur le tunning du WOAdaptor et de l'adaptor dont les valeurs défaut ne sont pas toujours bonnes.
Sous toute reserve, voici les valeurs de l'adapteur pour le MZStore :
- connect timeout : 5s
- send timeout : 20s (attention sensible en cas d'upload)
- receive timeout : 30s
- retries : 3
- Dead (dormant) : 20
Pour les reglages de l'applications, voici les paramètres expliqués :
WOListenQueueSize : c'est le nombre de requetes empilées par instance. Si cette valeur est trop importante, l'instance va de toute facon les traiter meme si elle est incapable de renvoyer le resultat parce que la connexion avec l'adapteur est interrompue. Par défaut, la valeur est 128 mais c'est visiblement beaucoup, beaucoup trop car je n'ai rien trouve ds mes notes mais j'ai le souvenir d'une valeur autour de 4 a 10 !
WOWorkerThreadSize : le nombre de threads actifs c'est à dire les process traitant les requetes ou attendant après un verrouillage. Le nombre max par défaut est de 256. La aussi, il faut le reduire "dramatiquement".
Et toujours déployer en mode round robin.
Pour les explications sur les paramètres, consulter la doc WO
http://developer.apple.com/documentation/WebObjects/Deployment/Deploying_Applications/Reference/chapter_8_section_2.html
Max Muller termine sa présentation en donnant quelques conseils sur les accès BD.
- détecter les trop larges fetches dues principalement aux relations bidirectionnelles
- faire des stats sur les editingContext (quand ils sont crees, les objets enregistres, ...)
- faire des stats sur les requetes SQL les plus utilisees de facon à faire des prefetches
Deux questions ont principalement retenu mon attention :
L'equipe du MZStore utilise t'elle une version speciale de WO ?
"Non, nous utilisons une version standard." L'équipe WO a ajouté qu'ils avaient une certaine pression pour faire évoluer WO.
L'equipe du MZStore utilise t'elle D2W, ProjectWonder ou bien Java Client ?
"Les 3" a repondu Max Muller
|
|
|
|
|
|
|
|
|
|
|
