blog

Résultats de la phase de qualification

publié le 30 mai 2011 à 06:03 par Utilisateur inconnu

Les tirs de qualification se sont achevés ce midi.
Avec 3 semaines de retard, il est vrai, mais avec la sensation d'avoir donné au maximum sa chance à chacune des équipes en compétition.

Des 50 équipes initialement inscrites…
    … des 20 équipes retenues pour participer au concours…
        … seules 9 courageuses équipes ont tenu bon jusqu'aux qualifications.
Certains se sont battus jusqu'à la toute dernière minute, avec plus ou moins de bonheur.

Les teams 4, 5, 6, 8, 10, 11, 14, 16 et 17.

Et la phase de qualification du concours ne retient les 3 meilleures sur les critères de performance scalable et de résilience.

Les équipes retenues sont les suivantes :
  • Team08 avec 33691 utilisateurs simultanés,
    • un temps de réponse moyen de 2,84 ms
    • et un temps max jamais supérieur à 300 ms
  • Team10 avec 35570 utilisateurs simultanés,
    • un temps de réponse moyen de 3,24 ms
    • et un temps max jamais supérieur à 250 ms
  • Team16 avec 44838 utilisateurs simultanés,
    • un temps de réponse moyen de 5 ms
    • et un temps max jamais supérieur à 350 ms
Pour aucune de ces 3 équipes nous n'avons atteint la limite de dégradation de l'application avec 8 injecteurs au maximum.

Chacune des 9 équipes en lice jusqu'à aujourd'hui a proposé sa vision de l'architecture distribuée et nous espérons que vous aurez l'envie de partager avec nous sous forme d'interview vos points de vue et opinions sur le challenge.
C'est tout l'esprit de ce challenge de partager les compétences acquises lors de cette expérience commune.


Bravo, en tout cas, pour votre engagement sans faille.

Et vous pouvez dès à présent débattre sur ce forum.

Retard dans les qualifications

publié le 30 mai 2011 à 06:03 par Utilisateur inconnu

Bonjour,
A la date limite de publier les résultats, déjà retardée de 15 jours, nous ne pouvons toujours pas donner de classement définitif.
Pourtant, ces 2 dernières semaines ont été quasiment dédiées à plein temps au challenge.
 
Divers problèmes se sont présentés:

  • absence de doc d'architecture et/ou de logs, qui font des applications des boîtes noires.
  • incapacité des applications à subir un reboot
  • specs non-respectées (format JSON, feature absente, protocole HTTP), malgré la disponibilité de l'injecteur pour qualifier la conformité aux specs.
  • certaines specs imprécises, également, (notamment sur le classement à produire).

Très clairement, pas une application ne répond pleinement aux critères souhaités et définis par les organisateurs.
Divers choix s'offraient à nous :
  • annuler le concours purement et simplement,
  • ne retenir que les applis fonctionnellement conformes, mais aux performances décevantes,
  • tenter de mettre en conformité le maximum d'équipes pour obtenir les résultats les plus intéressants.

Nous avons fait le pari de pousser les investigations pour essayer d'obtenir des résultats pertinents à l'issue du concours.

Que se passe t il maintenant ?

Le planning est à adapter.
La dead line qui ne peut pas bouger est l'USI - 28 et 29 juin. A cette date, nous devrons annoncer le gagnant.
Par ailleurs, nous souhaitons maintenir la phase à 20 VMs applicatives.
Nous proposons donc le planning suivant:
  • Le 6 juin, annonce des 3 équipes finalistes et classement des autres. Les finalistes seront inscrits à l'USI.
  • Le 7 juin, fourniture des 3 VApp configurées avec 30 VMs : 20 VMs applicatives et 10 VM d'injection.
  • Le 17 juin, livraison des plateformes avec 20 VMs prètes au snapshot.
  • Les 28/29 juin annonce du classement des 3 finalistes. 

Nous sommes désolés de décaler tout le plan prévu mais sommes sûrs que vous comprenez l'intérêt d'avoir un maximum d'applications fonctionnelles dans le concours.

Modification du scénario 'game_play' et de la génération des données de test

publié le 14 avr. 2011 à 13:13 par Utilisateur inconnu

Une nouvelle version du script 'prepare_data.py' ainsi que du scénario 'tsung_game_play.xml' sont sur le dépot GIT.

Les modifications apportées:
  • il y avait un bug dans la génération ds données de tests. Les classements 'before' ou 'after' étaient erronés dans le cas de joueurs ayant le même score.
  • Le temps de pause minimal entre la réponse à la dernière question et l'appel à /api/ranking ne correspondait pas aux diagrammes de séquences spécifiés. Ainsi, la valeur minimale de thinktime est passé de 3 à 8 secondes.

Mise à jour des specs et des scénarios d'injection

publié le 1 avr. 2011 à 09:16 par Utilisateur inconnu

Les specs ont été modifiées:
  • Le champ "nbquestions" présent dans les paramètres envoyés lors de POST /api/game ne sera pas utilisé.
  • Les retours de GET /api/rank et /api/score contiennent seulement les 10 joueurs avoisinants (contre 100 précédemment)
Par ailleurs, les scénarios d'injection ont été modifiés:
  • Utilisation du port 80 au lieu de 8080
  • C'est bien le code 201 Created qui est testé lors d'un post (et non 200)
Enfin, le fichier qui génère les données de test crée les valeurs 'null' pour les tableaux JSON qui doivent être vides.

Test des valeurs retournées dans les scénarios d'injection

publié le 29 mars 2011 à 09:31 par Utilisateur inconnu

Le dépôt GIT a été mis à jour pour tester les valeurs qui sont retournées à l'injecteur.

Vous trouverez un script python nommé 'prepare_data.py' au sein du nouveau repertoire 'test_data'.
Ce fichier prend en paramètre le nombre de joueurs du test, puis génère un ensemble de fichiers dans 'injector_1/output'.

Copiez ensuite les fichiers générés dans 'game_play' et 'game_audit'.

N.B : si les fichiers CSV à parser sont trop gros, TSUNG lance des timeouts. Pour éviter cela vous avez deux solutions:
  • limiter les tests à 5000 joueurs.
  • retirer les chargements des fichiers 'before_XXX' et 'after_XXX' et par conséquent les assertions faites sur /api/ranking et /api/score.
Prochaine étape : les vérifications des temps.

Mise à jour des specs et injecteur

publié le 16 mars 2011 à 15:54 par Utilisateur inconnu

Les scénarios d'injections sont (enfin!) disponibles sur le GIT de SourceForge.

Pour plus de détails, consultez la page dédiée à l'injecteur.


Pour terminer, les spécifications ont été mises à jour pour éclaircir certains points ou corriger des erreurs:
  • Concernant /api/ranking
    • Dans le cas d'ex-aequo (même score), les listes seront triées selon lastname/firstname/mail.
    • La structure du retour est la même, mais certains champs ont été renommés (my_score -> score, before_me -> before, after_me -> after).
  • /api/score : le retour est identique à celui d'api/ranking.
  • /api/score, /api/audit et /api/audit/n : les paramètres d'appels (authentication_key et user_mail) ne sont dans le corps du message mais dans l'URL.

Mise à jour des specs

publié le 4 mars 2011 à 12:22 par Utilisateur inconnu

Une nouvelle page a été ajoutée pour détailler les séquences d'appels.

En outre, comme mis à jour sur la page de protocole de test, le temps de re démarrage des VM sera de 5 minutes entre le demande de redémarrage des VMs et les premiers appels à GET /api/ranking - et non pas 3 minutes.

Enfin, voici l'extrait d'un ticket GitHUB explicitant quand pourra se faire le redémarrage des VMs :Le redémarrage peut intervenir immédiatement lorsque les classement peuvent être appelés. D'où la question : quand les classements pourront être appelés ? Tous les utilisateurs devront répondre à la dernière question avant la fin du timer questiontimeframe (5 à 10 secondes). Au bout de ce temps, l'application à toutes les réponses et dispose d'un temps 'synchrotime' pour agréger le classements (ou finir l'agrégation si elle l'a fait au fur et à mesure de la partie). Ce temps 'synchrotime' est un nouveau paramètre fourni par un appel à /game, de l'ordre de quelques secondes (entre 3 et 5). Au bout de ce temps, 'synchrotime' les VMs pourront être redémarrées. Si elles ne sont pas redémarrées, l'application recevra les requètes /ranking et y répondra en moins de 350 ms. 

Ouverture de 2 projets USI2011 sur SourceForge.Net

publié le 28 févr. 2011 à 14:14 par Utilisateur inconnu   [ mis à jour : 28 févr. 2011 à 14:42 ]

Depuis la présentation vFabric du 16 février, il est apparu évident que les tickets GitHub et les e-mails n'étaient pas les outils idéaux pour communiquer entre l'organisation et les équipes en compétition.
Nous voulons une communication ouverte et bi-directionnelle.
Mais nous voulons aussi pouvoir restreindre l'accès à certaines informations à la seule sphère des équipes en compétition.
C'est le cas, notamment, de tout ce qui touche aux infrastructures mises à disposition par VmWare et Stéria.

Nous avons donc cherché un outil gratuit, en SaaS, qui saurait faire ce job. De GitHub à BitBucket, de CodeHaus à Google Code, rien ne répond vraiment à ce double besoin de gestion de droits ouverts et privés.
Nous est même venu l'idée d'installer un Redmine ou autre Jira/Confluence, sur un PaaS, mais le jeu n'en valait quand même pas la chandelle : nous avons des injecteurs et des moulinettes d'audit à préparer.

2 projets usi2011 dans SourceForge.net

Notre choix s'est finalement porté sur l'ancêtre de toutes les forges publiques : SourceForge.net
Une nouvelle plateforme en version bêta répond à nos besoins de facilité d'administration tout en restant ouverte avec une gestion de droits acceptable.

Au menu, un projet usi2011, donc avec :
  • outil de ticketting
  • forums (enfin !)
  • Wiki
  • dépôt Git
Ce projet est ouvert à tous en lecture, pour contribuer, il faut être inscrit (une OpenID ou une adresse GMail suffit) et être membre du projet.

Un sous-projet usi2011-cloud fournit lui aussi tickets / forums / wiki, mais à la seule population des membres du projet (c'est à dire vous, chers compétiteurs).
Comme son nom l'indique, il est plus spécifiquement dédié à héberger les discussions concernant la plateforme de cloud privé que nous utilisons pour le challenge.

En particulier, vous y trouverez dès à présent la version finale du doc d'infrastructure rédigé par VmWare.


Je vous invite donc à vous inscrire au plus vite sur SourceForge.Net et sur les 2 projets usi2011 et usi2011-cloud, que nous puissions commencer à échanger comme il se doit.

Décommissionnement des tickets GitHub et du mini-blog Google Sites

Concernant GitHub, il reste ouvert jusqu'à migration complète des tickets sur SourceForge.Net, mais nous décommissionnerons l'outil de ticketting associé dès que possible, pour limiter les maintenances en double.
De même, ce mini-blog doublonne dès à présent avec les forums du projet principal dans SourceForge.Net, il deviendra donc inactif dès que vous aurez rallié les projets usi2011 sur SourceForge.Net

 Désolé pour cette nouvelle migration que nous vous imposons. Et nous bossons d'arrache-pied pour reprendre une (ré)activité normale au plus vite.

Mise à jour des specs suite aux tickets GitHub

publié le 18 févr. 2011 à 11:09 par Utilisateur inconnu

Voici les mises à jour du site qui font suite aux tickets GitHUB:
- dans le protocole de test, le temps de re-démarrage des VMs ne doit pas excéder 3 minutes.
- l'IHM web doit être compatible Firefox >= 3.5
- concernant les tailles des champs textes, pour les données utilisateurs (nom, prénom, mail, password), la taille est de 2 à 50 caractères. Pour les questions et réponses, les tailles sont de 2 à 150 caractères.
- un fichier utilisateurs est disponible dans le section 'Docs'. Il s'agit de 1million_users_1.csv.zip


Présentation SpringSource vFabric par VmWare

publié le 7 févr. 2011 à 07:10 par Utilisateur inconnu   [ mis à jour : 15 févr. 2011 à 13:34 ]

J'ai le plaisir de vous inviter à assister à une présentation de la suite logicielle SpringSource vFabric, mise à la disposition de chaque équipe en compétition lors du challenge USI2011.
Cette présentation sera l'occasion pour VmWare, sponsor du challenge USI2011, de présenter l'usage potentiel des différents modules qui constituent vFabric dans le contexte de haute scalabilité nécessité par le concours.

Cette présentation donnera lieu à une diffusion WebEX en direct et en différé.
La salle étant relativement petite, inscrivez-vous sans tarder.

La présentation aura lieu
le mercredi 16 février 2011,

entre 18h30 et 20h,

chez Octo Technology (salle André Gide, 5e étage),
50, av. des Champs Elysées
75008 Paris

Mise à jour du 15-févr-2011 :
Les informations pour suivre la retransmission de la présentation en direct ont été envoyées par e-mail à toutes les équipes en compétition.

1-10 of 17

Comments