Bonjour,

je suis développeur dans une agence web et nous avons récemment du mettre en place un système de webconférence maison pour un public de médecins.

Merci, si vous êtes patients, de me lire car je vais expliquer ce que contient l'appli, les technologies utilisées (dont l'Ajax, je ne suis pas hors sujet), les angles choisis et les problèmes qui ont résulté. Ensuite je vous listerai les points sur lesquels je cherche à prendre des décisions pour que vous puissiez éventuellement me conseiller... Merci donc de votre patience, long message en suivant ;-)

Le projet:
  • Un outil de "web-conférence" à destination d'internautes spécifiquement invités (par mailing) avec un code unique à utiliser pour y accéder à une tranche horaire fixe
  • Une interface dans une page web, statique, sans rechargement de page, qui contient trois zones bien séparées :
    • une zone où est diffusée une vidéo en direct (orateurs commentant ce qu'il se passe sur le reste de l'interface) - la vidéo est distribuée par un point de montage chez un professionnel de la transmission d'évènements directs sur le web, cette zone là est donc hors de notre champ d'action et ne pose à vrai dire pas de problème
    • une zone, la plus grande, où est affiché le contenu, graphique, textuel ou Flash, actualisé en temps réel - le contenu provient de pages asp / html et est actualisé par une routine Ajax
    • une dernière zone, plus petite, dédié à une interface de chat allégé : les spectateurs peuvent déposer des messages, visibles seulement par le modérateur et n'y voient ensuite apparaitre que des messages envoyés par le modérateur, soit à l'internaute seulement, soit à l'ensemble des spectateurs - là aussi, le contenu de cette zone de chat est alimenté par une routine Ajax


A ce stade, je peux commencer à vous expliquer quel est le problème que nous avons rencontré avant de vous lister les points sur lesquels je me pose des questions...

L'interface en action:
Une fois le développement terminé en interne, et après avoir fait quelques tests avec des gens de ma boîte (sans soucis), nous sommes passés à une fausse première conférence, dans les conditions du direct, mais avec un public constitué de membres de la compagnie commanditaire du projet. Le public, en pointe, lors de ce test, était de 60 à 80 personnes en simultané.
Là aussi, lors de ce test, aucun problème rencontré (sinon l'incompatibilité de certains navigateurs exotiques ou obsolètes utilisés par 3 ou 4 des internautes présents). L'affaire est donc dans la boîte, le client est content et signe pour un pack de réunions à suivre.
Arrive la première vraie réunion avec un public cible de 300 médecins...et là... la catastrophe : tout le monde se loggue en même temps, tout le monde cherche à faire un petit coucou dans le chat, le contenu de la zone principale de visualisation ne s'actualise plus et les gens, en retour, surchargent l'interface de chat pour dire que "ça ne marche pas votre truc".
Résultat des courses, le serveur n'arrive plus du tout à suivre et notre seul moyen de communiquer avec le public est la zone vidéo qui, elle, continue à bien tourner (serveur extérieur)... LA CATA !!!!!!

Les points que je cherche à améliorer:
Il me faut donc chercher à résoudre le problème et à soumettre une nouvelle réunion, toujours avec le même public (250 à 350 personnes). Voici les choix techno que j'ai fait et les options qui s'offrent à moi...

  • notre "mini site" est hébergé sur un serveur dédié que nous utilisons, sans problèmes majeurs, depuis des années. La première décision a donc été de chercher un serveur plus puissant, par sécurité, avec de meilleures garanties de bande passante
    • Mon boss à l'air de s'être décidé pour un serveur chez Magic... des avis sur eux ?
  • l'interface utilisateur, ainsi que celle d'admin ("passage des dias" / switch du contenu de la zone principale, administration du chat) ont été développés en ASP et JavaScript avec quelques routines Ajax maison (mais assez basiques), le tout reposant sur du contenu (index des pages à afficher dans la zone de contenu, messages du chat, listing des utilisateurs enregistrés) stocké dans une BDD fichier (un .mdb)
    • Questions sur ces points : connection à la BDD, DSN ou DSN-less ? Plutôt que des appels répétés et massifs à la base de données, plutôt écrire le nom ou l'index de la page à afficher au moment où la routine Ajax contrôle à quelle page nous en sommes dans un fichier texte (moins gourmand en ressources ou pas d'ouvrir en lecture un fichier texte que d'ouvrir une BDD ?) ? Idem pour les messages du chat, les écrire, format XML, dans un fichier texte ou bien générer du XML en lisant la BDD à chaque routine d'actualisation ?
  • Mes routines Ajax s'enchaînent pour le moment (3 secondes d'attente et on va récupérer le nom de la page à afficher pour voir si on est passé à la page suivante, puis 3 secondes d'attente et on va contrôler la liste des messages adressés à un utilisateur en particulier, puis on recommence), chaque fois, le contenu n'est pas formaté XML mais récupéré sous forme de ResponseText :
    • ne vaudrait-il pas mieux faire une seule routine qui génère un seul fichier XML, mettons toutes les 7 secondes, fichier dans lequel un premier noeud indiquerait le nom de la page à afficher, un second noeud listant les nouveaux messages éventuels à afficher dans l'interface de chat de l'utilisateur ?
  • le contenu de la zone principale provient donc de pages pré-créées, dans la plupart des cas ces pages n'ont pour contenu qu'une simple image (export graphique d'un diaporama PowerPoint), mais occasionnellement cette page pourra contenir un élément Flash interactif ou bien un contenu généré directement par la base de donénes (exemple : on demande dans la zone principale aux utilisateurs de choisir une réponse parmi cinq, la page suivante montrera un graphe indiquant comment les spectateurs ont voté). Je suis donc un peu tenu à avoir du contenu "HTML" affiché dans cette zone, pas seulement des images. Ceci a entraîné un gros problème lors du développement : si je ne mets pas sur chacune de ces pages une balise méta interdisant la mise en cache de ladite page, le contenu de la zone dynamique ne s'actualisait pas dans Internet Explorer (merci Microsoft...). Ceci m'empêche de contourner un problème de bande passante en pre-loadant toutes les images qui seront amenées à être affichées par la suite avant le début de la session... Quelqu'un aurait-il une piste pour ce problème ?
  • Enfin, dernier problème et pas des moindres : la rémanence des informations... par habitude, j'ai utilisé l'objet Session pour stocker pas mal d'infos côté utilisateur (l'utilisateur arrive sur l'interface, saisit un code d'accès unique et se voit attribué un nom d'utilisateur pré-défini, stocké dans l'objet Session, par la suite on stocke aussi dans son objet Session l'ID du dernier message qui lui était adressé et qui ait été affiché dans son interface, afin de ne retrouver que les nouveaux messages postérieurs lors du prochain tour de la routine Ajax destinée à récupérer les nouveaux messages... bref, un public de 300 utilisateurs entraine au bas mots 600 items de Session à gérer pour le serveur... Ne vaudrait-il pas mieux utiliser des Cookies ? Lorsque l'on fait un Request.Cookies depuis le serveur, il va récupérer les données depuis le navigateur de l'utilisateur, est-ce que malgré cette utilisation (légère) de bande passante supplémentaire, ça n'allègerait pas le serveur en terme de charge par rapport à une indexation massive d'objets Session ?


En ce qui concerne l'Ajax à proprement parler, les deux routines principales que j'utilise se présentent ainsi :

Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
function routine1(){
	var zoneChat = document.getElementById("showChat");
	getXhr()
	xhr.onreadystatechange = function(){
		if(xhr.readyState == 4 && xhr.status == 200){
			if (xhr.responseText!="") {
			zoneChat.innerHTML += xhr.responseText;
			zoneChat.scrollTop = zoneChat.scrollHeight;
			}
		}
	}
	xhr.open("GET","routine1.asp",true);
	xhr.send(null);
	setTimeout( "routine2()", 3000 );
}

function routine2() {
	var zoneContenu = document.getElementById("showDias");
	getXhr()
	xhr.onreadystatechange = function(){
		if(xhr.readyState == 4 && xhr.status == 200){
			if (xhr.responseText!="") {
				zoneContenu.src = xhr.responseText!;
			}
		}
	}
	xhr.open("GET","routine2.asp",true);
	xhr.send(null);
	setTimeout ( "routine1()", 3000 );
}
Ces deux routines sont donc séquentielles, et il existe une routine AJAX supplémentaire, utilisant POST, activée lorsque l'utilisateur a saisi un message dans la zone de chat et appuyé sur "Envoyer votre message". Lorsqu'il appuie, les timeOut sont vidés, le message part dans la base de données, et lorsque on reçoit un ReponseText disant que le message a bien été enregistré, on redémarre la boucle séquentielle précédente en relançant la routine 1...

Je chercher donc un peu tous les points que je pourrai améliorer avant notre prochaine session en live, où nous n'avons du coup aucun droit à l'erreur... et comme je n'ai pas encore trouvé de solution me permettant de tester l'appli en simulant 300 utilisateurs en simultané, je navigue un peu à l'aveugle...

Merci à ceux qui sont arrivés jusqu'à cette ligne de m'avoir lu, je surveillerai cette discussion pour voir si certains d'entre vous ont des conseils particuliers à me donner !

Amicalement
DangerMo