 | Cette information est obsolète. Les développements de sites web autour de Mercator se font maintenant |
MercatorIshop fonctionne par défaut en tant qu'instance unique sur le serveur. Ceci peut être imagé comme suit : un seul utilisateur est à l'écoute des demandes des Internautes, en prend connaissance dans leur ordre d'arrivée et y répond dans ce même ordre. Un problème peut se poser si une demande requiert un temps d'exécution long. Dans ce cas, toutes les demandes ultérieures sont mises en attente. Si le délai devient supérieur au timeout fixé dans le FoxIsapi.ini (busytimeout), alors les internautes "non servis" recevront un message "FoxIsapi call failed : timeout ..."
Une solution consiste à configurer le serveur web de la sorte qu'un second, voir un troisième utilisateur puisse répondre aux demandes non traitées par le premier. En jargon MercatorIshop, ces utilisateurs s'appellent des instances.
L'activation d'un nombre d'instances possibles supérieur à 1 ne doit se faire que si le serveur est capable de le supporter. Ceci en terme de processeur (multiprocesseurs idéalement requis) et mémoire RAM disponible élevée. Si ces critères ne sont pas remplis, le démarrage de la seconde instance sera grevée par l'activité (par définition intense) de la première instance et le gain en performance sera nul voire négatif.
Il n'est pas non plus opportun de fixer un nombre élevé d'instances. Le nombre d'instances ne devrait jamais être supérieur à 3, hormis l'utilisation d'un serveur aux performances et à l'activité démesurée.
La fixation du nombre maximal d'instances se fait dans le fichier foxisapi.ini. Il suffit d'y ajouter ce bloc :
[MercatorIshop.MercatorIshop]
MercatorIshop.MercatorIshop=3
ou, par exemple, pour un MercatorIshop2.exe
[MercatorIshop2.MercatorIshop]
MercatorIshop2.MercatorIshop=3
Pour confirmer cette configuration, il faut encore apporter les modifications suivantes :
- Installer une mise à jour 6.2 de MercatorIshop ou ultérieure
- Pour accélérer le démarrage de la seconde instance, il est impératif d'optimiser la taille de buffers.
- Dans les options de MercatorIshop, mettre l'option "Del. caddies at startup" à NO. Sinon, le démarrage de l'instance n°2 détruira les cookies (et donc les caddies en cours) de l'instance n°1
- Ne plus utiliser la méthode reset de MercatorIshop (cfr. infra)
Il faut bien prendre conscience du fait qu'aucun processus ne permet de savoir quelle instance sera utilisée pour traiter telle ou telle commande d'un internaute. Il se peut qu'un internaute commence un caddie via l'instance n°1, que l'ajout d'un articles se fasse par l'instance n°3 mais que la validation se fasse par l'instance n°2. Dès lors, il ne faut pas utiliser de variable globale qui devrait être récupérée entre 2 actions d'un même internaute (il faut utiliser la table COOKIES qui est bien commune à toutes les instances).
Une fois la gestion des instances multiples activée, la commande Status sur foxIsapi.dll renvoie un tableau contenant autant de ligne que d'instances. Ce tableau permet de visualiser si l'instance existe (l'objet MercatorIshop y correspondant existe) ou pas.
Cette même URL, mais en remplaçant status par reset permet de "relâcher" toutes les instances de MercatorIshop. Ce reset est à préférer au reset propre à MercatorIshop dans le mesure où le reset sur foxisapi.dll indique bien à cette dll que les instances n'existent plus et qu'il faut donc les recréer pour satisfaire les demandes suivantes.
(Les URL reset et status ne sont nullement protégées par un mot de passe, il convient de les renommer avec un nom "non trivial". Ceci peut se faire en modifiant les valeurs des entrées statusurl et reseturl se trouvant dans le fichier foxisapi.ini.)
Comment tester le fonctionnement en instances multiples ?
Mercatorishop 6.2 dispose d'une méthode delay, qui permet de bloquer une instance pendant un nombre de secondes déterminé. Dans l'intervalle, une autre instance devra immanquablement prendre le relai. (exemple : /scripts/foxisapi.dll/MercatorIshop.MercatorIshop.delay?30)